| 18:27 | <Rob Palmer> | I invited Jake here because he has done a lot of work converting TypeScript to use ESM. There are still some challenges before TS can go "fully ESM". Potentially Joyee/Guy/Nicolo may have some thoughts on this. |
| 18:29 | <jakebailey> | Hello π |
| 18:29 | <kriskowal> | Greetings jakebailey, very interested in your perspective / grievances. |
| 18:33 | <guybedford> | Hi jakebailey Rob's mentioned some of your use cases, would be great to discuss further either here or in our weekly meetings if you'd like to join |
| 18:43 | <jakebailey> | More or less, the issue with switching TS to ESM is that TypeScript has conditional support for Node; we check if we're in Node (or Node-ish), then require stuff from Node if possible. This is good because the same bundle can be used for any use case. But, we can't do this in ESM without top-level await because this code can't be asynchronous (besides during load of the module), defeating the awesome "require ESM works" case that would allow us to move to ESM-only without breaking downstream CJS users. My thinking was that import.meta.require or a new import.meta.importSync or import(..., { sync: true }) could be created to allow synchronous dynamic import of synchronously loadable ESM; as it stands, the only use of "synchronous ESM" seems to be require-ing ESM. |
| 18:46 | <jakebailey> | It's theoretically possible to do this with import mappings, but that has a bunch of bad knock-on effects for our build, plus the fact that it may exclude downstream consumers who polyfill or aren't actually Node |
| 18:46 | <guybedford> | This was one of the motivations for top-level await to make these workflows easier. I'm curious what the issue is with relying on it? import sync is a great discussion point, I suppose the important question there is whether or not you expect to synchronously load arbitrary modules in Node.js through this mechanism or just the builtin host APIs or already-loaded code |
| 18:47 | <jakebailey> | TLA prevents require of ESM, so we'd sooner stay CJS because most of the TS ecosystem is CJS. |
| 18:47 | <guybedford> | most tools these days support package imports conditions as well |
| 18:47 | <jakebailey> | This is all relating to Joyee's change to Node, which would typically mean that an ESM only project would be usable in CJS via require |
| 18:48 | <guybedford> | it sounds like your major pressure is on import sync then yes, in which case it would be interesting to hear what modules you expect the import to work for |
| 18:49 | <kriskowal> | Also curious how we would square this with TS-to-ESM on the web. |
| 18:49 | <jakebailey> | Well, for us, it's just like require("fs") and so on; but I think there's a more general question about "if there's now a very clear set of sync-loadable ESM code, isn't it nice for anyone to be able to load that sync too?" |
| 18:50 | <kriskowal> | Moddable XS also has a sync import but it only is expected to work for no-TLA subgraphs that have already been loaded. |
| 18:50 | <jakebailey> | And IIRC there are some ongoing module related proposals that also require sync ESM, and even a proposal to have a prologue to assert that |
| 18:51 | <kriskowal> | Yes, there is a proposal for asserting a no-TLA subgraph, and also a proposal (deferred export evaluation) that under the same circumstances synchronously export pre-loaded no-TLA subgraphs. |
| 18:52 | <jakebailey> | Yeah. So on one hand, I'd be happy with import.meta.require being re-proposed, especially now that Node has import.meta.dirname and such, but there's the more general solution too! |
| 18:52 | <kriskowal> | Itβs not hard to imagine an import.now proposal that would work under the same limitations. |
| 18:53 | <guybedford> | this is a good discussion topic, I'd suggest we bring it up in our next meeting if you'd like to join |
| 18:53 | <kriskowal> | import.meta.dirname, import.meta.filename, import.meta.resolve, and import.meta.require are all difficult to generalize beyond host-specific bottlenecks for interoperability. |
| 18:53 | <guybedford> | The meeting is this one - https://www.google.com/calendar/event?eid=c2luNm9jcm4wbTJyNXNxY2JkbGZtdmdwZWNfMjAyNDA0MThUMTUwMDAwWiAzN2EyMTA3ZGZmMTUxOTNiNDJmZmZhMDkxYmM5OTkxNjU2OTVkNDNiN2U0ZjQzYjY1ZWFiMDkzZGEyNzU3YTNhQGc&ctz=America/Chicago |
| 18:53 | <jakebailey> | I'll add that to my calendar π |
| 18:54 | <kriskowal> | But, import.now does generalize. |
| 18:54 | <jakebailey> | I also remember some oddities in Workers too where a sync import would be beneficial, though I'm leaving my sphere of knowledge π |
| 18:56 | <guybedford> | it's worth thinking carefully about what the real use cases are though |
| 18:56 | <guybedford> | as opposed to "it might be nice" |
| 18:56 | <guybedford> | there's a big distinction between host apis / a registry cache getter and full sync graph loading as well |
| 18:57 | <guybedford> | so if we want to solve the full sync graph loading problems (which are hard, because network), it's important to justify that |
| 18:57 | <guybedford> | hard in the sense of, how should it work and how should it error, not how should we syncify the network of course |
| 19:00 | <guybedford> | there's definitely some interesting framings in which a sync import can work though, so it would be great to have a chance to discuss the use cases and viability |