tracking issue: async loader for module interop

[Trott]

@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
• 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 require would have found something

[MylesBorins]

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]

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]

Nice to see this coming a long. That said I'm really worried about the choice of .mjs for 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]

@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]

@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]

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]

@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]

Browsers already accept the new extension (or any extension you wish; extensions are not used in browsers). .mjs works fine there.

[RobertWHurst]

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]

It's a shame that Node can't be as flexible as browsers when it comes to file extensions.

[jkrems]

@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]

move all discussion on things related to resolution/detection to nodejs/node-eps#13 please

[Trott]

@bmeck This is still being used, right? Is it OK to put a help wanted label on this for any eager folks wanting to implement this stuff Or would that be unhelpful/counterproductive?

[bmeck]

Pr is open, closing is fine

…

On Jul 29, 2017 10:09 PM, "Rich Trott" ***@***.***> wrote: @bmeck <https://github.com/bmeck> This is still being used, right? Is it OK to put a help wanted label on this for any eager folks wanting to implement this stuff Or would that be unhelpful/counterproductive? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#11233 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOUo094nGsg8W4ccdZUeDnafJcE6yfJks5sS_QFgaJpZM4L6bDG> .