01:01
<kriskowal>
I believe import.now is still at Stage i, as in imaginary
01:03
<kriskowal>
But it would be coherent with XS compartment.importNow, which does at least have an explainer
01:05
<kriskowal>
MetaMask and Agoric are implementing a Compartment importNowHook presently, which would be hooked by import.now if the specified module hasn’t previously loaded (importHook returns a Promise so is ineligible in that case)
03:50
<jakebailey>
I patched createRequire into process on Node and then converted TS to ESM; it looks like a TLA-free ESM TypeScript public API is quite possible: https://github.com/nodejs/node/issues/52599#issuecomment-2084323892
04:35
<ljharb>
why does it need to be assigned to process? (you can require, or import, module, as needed)
04:35
<jakebailey>
That was one of the options we talked about in the meeting; a goal is that the ESM can be loaded into the browser and not fail due to not being able to resolve node's builtin modules
04:36
<jakebailey>
or, other non-node runtimes
04:41
<bakkot>
(you can technically shim out the node modules with import maps, but that is a huge pain for several reasons)
04:41
<jakebailey>
Yep; that was one of the alternatives, use import maps and a node condition, but I was not sure how at all that would interplay with bundlers, runtimes like Bun, or how you import that from a browser without it breaking (I am not familiar with import maps in a browser at all...)
04:42
<jakebailey>
Bun has import.meta.require which is effectively already what I want but I can understand why that's not very desirable 😄
04:46
<ljharb>
adding it to process would make it fail in the browser too tho, no?
04:47
<ljharb>
like, if you have to do a browser-specific transform or shim, why put it on process which doesn't exist in the browser?
04:47
<jakebailey>
Oh, this is me simulating the linked issue proposal, i.e. node provides this
04:47
<ljharb>
sure, but node provides the node core module module too
04:47
<jakebailey>
Or similar method to get sync conditional import
04:47
<jakebailey>
Yeah but I can't import that without import...
04:48
<ljharb>
ah ok, you want to provide require in ESM, but in browsers, there's no sync way to load things
04:48
<ljharb>
i mean, you could provide, in browsers, a require global, and that'd probably be "fine"
04:48
<jakebailey>
Right, but that's fine for us as that's only needed for node. That or import.now would do it too
04:49
<ljharb>
but the presence of a process global in browsers could break things if they're using it for env detection
04:49
<jakebailey>
The hack is just a hack to simulate having "any API" that does what we're looking for
04:50
<jakebailey>
We wouldn't modify process in our package at all, I'm just avoiding writing C++ to see what would happen 😅
04:55
<jakebailey>
Honestly, the most composable option overall feels like optional/weak imports, but the time horizon on that is dubious; you all would know better than me how to actually propose and drive that....