| 15:53 | <Jan Olaf Martin> | Is there a spot right now where “bundler conventions” could be documented or specified? A lot of this is tied to module resolution and import.meta but in ways that’s not 100% HTML spec, either. |
| 15:54 | <Jan Olaf Martin> | IMO this is a bit of a blindspot, standards wise, and leads to a confusing situation with “correct behavior” spread between node.js docs and various bundler’s own docs. And it’s very hard to determine which parts are interoperable or to what extent. |
| 15:57 | <Jan Olaf Martin> | Concretely this came up in a discussion with webpack maintainers about process.env.NODE_ENV vs import.meta.env.DEV vs some other API. (For context: https://github.com/webpack/webpack/pull/18876) |
| 16:10 | <Michael Ficarra> | @Jan Olaf Martin For module resolution, that's all intentionally left up to the implementations and we probably won't be adding new constraints there. But for import.meta properties, any of a number of standards venues could choose to standardise the name and meaning of a new property. The HTML spec defines url and resolve for instance. For something really generic like debug, TC39 seems an appropriate venue. |
| 16:14 | <Jan Olaf Martin> | @Jan Olaf Martin For module resolution, that's all intentionally left up to the implementations and we probably won't be adding new constraints there. But for |
| 16:15 | <Jan Olaf Martin> | I’m not sure TC39 could specify .debug because (at least imo), the semantics should be closely tied to module resolution semantics. And the semantics that are interesting in this context don’t exist anywhere but in tools. |
| 16:23 | <Michael Ficarra> | I think the fact that it is left up to implementers is what creates the “void” I’m talking about here. IIRC the best spec for module resolution across bundlers is a gist a webpack maintainer wrote that may or may not be up-to-date. Because tools usually implement a superset of browser resolution (citation needed), it’s hard to know which superset would work across tools, e.g. when writing a library. |
| 16:24 | <Michael Ficarra> | I’m not sure TC39 could specify .debug because (at least imo), the semantics should be closely tied to module resolution semantics. And the semantics that are interesting in this context don’t exist anywhere but in tools. debug to do, so that's possible, yeah |
| 16:29 | <Jan Olaf Martin> | I tried WinterCG first but from initial interactions, it seemed like their bias was (understandable) towards runtimes, not [build] tools. I'm not sure how much engagement there would be from tooling authors. But I just created https://matrix.to/#/#tc39-tools:matrix.org and I'll see if I can get this into the tools ecosystem outreach group scope, maybe. |
| 17:28 | <bakkot> | oh hey someone's doing a new coffeescript https://civet.dev/ |
| 17:47 | <Chris de Almeida> | kopi luwak is not for everyone |
| 19:42 | <Michael Ficarra> | cool! there were so many of them back in the day and then people just kinda stopped |
| 19:50 | <Michael Ficarra> | oh my, I even see a familiar face in the contributors list! ❤️ |
| 20:00 | <ljharb> | civet's been around for years i thought |
| 21:15 | <Chris de Almeida> | I tried WinterCG first but from initial interactions, it seemed like their bias was (understandable) towards runtimes, not [build] tools. I'm not sure how much engagement there would be from tooling authors. But I just created https://matrix.to/#/#tc39-tools:matrix.org and I'll see if I can get this into the tools ecosystem outreach group scope, maybe. |