Repository navigation
tracking issue: async loader for module interop #11233
Description
@bmeck Please feel free to edit the title or anything else if I'm being imprecise or worse with anything.
CTC has tentatively agreed to try implementing async module loading. This issue is being opened to have a central place to track progress, issues, conversation, questions, whatever.
Labeling ctc-agenda because we are probably going to want to talk about this at least a little bit every weekly meeting for a while.
- Docs
- CLI
- --module
- REPL
- 🚲 prepend full list of existing imports on every line / const declare them on global
- 🚲 warn on attempted export
- REPL
- --module
- Default ESM Loader
- Safe global cache manipulation
- 🚲
js:context- url - 🚲
node:context- require/__dirname/etc. - Hooks
- pre-resolve notification
- post-resolve notification
- VM Module bits
- import notification options on creating a Context
- vm.compileModule
- 🚲 vm.facadeModule (subset of WHATWG Loader Module)
- Expose Script::Module to JS
- Safe local cache
- import() support
- 🚫 awaiting v8
- require(esm) behavior
- add .mjs to require above .js (searches for CJS)
- 🚲 if no CJS fallback throw error saying to use
import()
- CJS -> ESM Facade
- ESM idempotency tests
- Cache propagation
- ESM idempotency tests
- Path algorithm
- errors include if
requirewould have found something
- errors include if
Activity
MylesBorins commentedon Feb 9, 2017
I'm beginning to research what APIs will be exposed by V8 to figure out what we will need to do in node to implement the loader.
I believe that Brad has done some of this work already, so hoping to sync with him when he gets back from vacation
targos commentedon Feb 9, 2017
Note that the API changes in V8 5.6 (I did not check 5.7).
Also V8 has implemented a basic loader in d8 for unit testing.
RobertWHurst commentedon Feb 23, 2017
Nice to see this coming a long. That said I'm really worried about the choice of
.mjsfor module detection. This will make isomorphic js much more difficult, and cause issues for tooling. This is the kind of wartiness and inconsistency that may drive people away from the platform. That all said I'm looking forward to seeing what ES6 modules look like in Node.ljharb commentedon Feb 23, 2017
@RobertWHurst in reality it will make it much simpler, and enable tooling to be much more straightforward and powerful as it determines how to parse, bundle, and serve CJS vs ESM. This isn't the place to debate it, though.
RobertWHurst commentedon Feb 23, 2017
@ljharb adding the new extension is effectively forking the language. That has negative consequences as well. I'd argue these consequences outweigh the benefits. But I'll leave it at that as you say. See you in another thread 😉
ljharb commentedon Feb 23, 2017
The spec adding a new parsing goal is what "forked" the language in the way you're describing; adding a new extension is the inevitable result of that, because the sole purpose of a file extension is to indicate a parsing goal.
RobertWHurst commentedon Feb 24, 2017
@ljharb I agree with that, I think theres a valid argument that it aught to be forked. A new modules system is a massive change, but that's not the precedent set thus far by the browser vendors or standards committees. I'd argue it's in Node's interest to align with the precedent the browser vendors put forth for the sake of interop. On the other hand, if we were able to push the browser vendors to accept a new extension then I think my concerns evaporate. Thanks 🍻
domenic commentedon Feb 24, 2017
Browsers already accept the new extension (or any extension you wish; extensions are not used in browsers). .mjs works fine there.
RobertWHurst commentedon Feb 24, 2017
Thanks for straightening my out on that @domenic. I didn't know that
<script src="file.mjs">would work. Just tried it and it totally does. Alright, that changes my position. That was my major concern, and now I'm totally on board. Rock on 🍻chrisveness commentedon Feb 28, 2017
It's a shame that Node can't be as flexible as browsers when it comes to file extensions.
hybrist commentedon Feb 28, 2017
@chrisveness It could be (and to some degrees it is). But it offers certain features that require file extensions (like automatically expanding filenames, loading JSON as data, hooks to compile other languages on the fly). But node can load files with random extensions as JS, just like a browser.
EDIT: Removed distracting side note.
bmeck commentedon Feb 28, 2017
move all discussion on things related to resolution/detection to nodejs/node-eps#13 please
Trott commentedon Jul 30, 2017
@bmeck This is still being used, right? Is it OK to put a
help wantedlabel on this for any eager folks wanting to implement this stuff Or would that be unhelpful/counterproductive?bmeck commentedon Jul 30, 2017