Guy Bedford
Guy Bedford
@weswigham this is effectively how the multiple loaders proposals work, yes. Resolvers are still flat in that anything can resolve anything, but defining a module is a process that can...
.js-based script config files is a really important class of bug - it could be worth having a dedicated issue for this one.
(this will affect most tools!)
@weswigham all discussions and decisions are as made publicly there, there have been no side agreements. If you disagree with fast tracking or merging it behind the flag we can...
(this issue was not discussed at the last meeting, because we were not yet aware of the compatibility case)
@weswigham as I say it is as a courtesy - we want to encourage experimentation of type module, and we don't want to cause unnecessary frictions in doing that, unless...
The major constraint for tools is that they often have synchronous config loading internals (I know at least Babel does /cc @loganfsmyth), so that using `import()` and falling back to...
> And `require("module-with-type-module/eslint.config.js")` is, by all rights, a module. what I'm asking is where is the actual _hazard_ in this case? How does it bite?
So to try flesh out the example - say you have a "type": "module" package on npm (P) and install it such that it has two dependents - one CommonJS...
Because `import.meta.resolve` is a common API between platforms, we need some interest from other implementers before unflagging. Domenic has made a similar proposal for the browser with roughly the same...