Managing fork and agreed upon minimal kernel

[MylesBorins]

Making this issue to track discussion and gain consensus around what a minimal kernel would look like in that fork.

[MylesBorins]

what would we want to call the fork? node-esm?

[devsnek]

how about a branch called esm, i'd like to still get eyes from collaborators who aren't node modules team members on our changes.

[MylesBorins]

So this is a good thing to discuss Fork vs branch. With branches on node core we have one less thing to worry about (a new repo) but are creating lots of noise for other collaborators (feature?) A new repo allows us a sandbox, but creates a separate place for conversations to go (aside from the modules repo) We could mount node as a Subtree in the modules repo and do pull requests. This is a bit of a spaceship though.

…

On Tue, Aug 14, 2018, 7:37 PM Gus Caplan ***@***.***> wrote: how about a branch called esm — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#166 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAecV2tJAv5E3xIFYj8w24X2QjAPV1mjks5uQ182gaJpZM4V9PxZ> .

[GeoffreyBooth]

The other thing to discuss is what should go in Node core. Do we keep the current implementation there? Replace it with a minimal one that grows over time? Remove it and leave nothing, and various implementations are all relative to an ESM-less core?

[giltayar]

+1 for fork. Until we know where this is going, the less noise, the better.

…

On Wed, Aug 15, 2018 at 8:05 AM Geoffrey Booth ***@***.***> wrote: The other thing to discuss is what should go in Node core. Do we keep the current implementation there? Replace it with a minimal one that grows over time? Remove it and leave nothing, and various implementations are all relative to an ESM-less core? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#166 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAYnRBoi7ACb_StNumCRiGnzeZ6ufAwNks5uQ6wjgaJpZM4V9PxZ> .

[giltayar]

What should go in? Leave everything as is, as this is the easiest, and start discussing what should be taken out. (or put in.)

…

On Wed, Aug 15, 2018 at 10:15 AM Gil Tayar ***@***.***> wrote: +1 for fork. Until we know where this is going, the less noise, the better. On Wed, Aug 15, 2018 at 8:05 AM Geoffrey Booth ***@***.***> wrote: > The other thing to discuss is what should go in Node core. Do we keep the > current implementation there? Replace it with a minimal one that grows over > time? Remove it and leave nothing, and various implementations are all > relative to an ESM-less core? > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#166 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAYnRBoi7ACb_StNumCRiGnzeZ6ufAwNks5uQ6wjgaJpZM4V9PxZ> > . >

[giltayar]

Let me suggest a minimum implementation. The idea of this minimum is to 1) have all ESM functionality included, and 2) avoid a debate on all the thorny issues.

So it includes:

• the ability to import an ESM either with import from in an ESM file, or using dynamic import from a CJS or ESM

Avoiding the "file extension debate"

• import will not guess the file extension and will import the file as ESM:
  • e.g. import ... from './foo.js' or import ... from './foo.mjs' will both import an ESM from the corresponding files because the extensions have no meaning. It could be ./foo.foo for all it cares! It is important to note that this will probably not be the end result, but is again, a minimal decision that will likely change, and that avoids discussing the file extension problem till we're ready.
• If the thing being imported is a folder, it will look for package.json main property and will load that as ESM. Again, will not guess the file extension.
• It will not look for index.js because that will provoke a "file extension debate", and we all want to evade that.
• The regular CJS folder searching algorithm will be used (e.g. node_modules in parent dir...), except that it will not look for index.js (or index.mjs).

Avoiding the "transparent interop debate"

• CJS will be able to dynamically import an ESM, because that is in the JS spec, and is mostly a consensus in the group (I hope...).
• ESM will not be able to require a CJS file.
  • If this is too harsh, we can add the import.meta.require PR to enable this, as this is easily removable later if another interop mechanism is chosen.

That's it.

[devsnek]

It will not look for index.js because that will provoke a "file extension debate", and we all want to evade that.

node looks for index.{any registered file extension} atm, will we still support that with your proposal?

[GeoffreyBooth]

I think folder lookup can be something else that gets added later. If you really want to be minimal, you could also leave out package resolution, to allow for either the CommonJS require algorithm or the package name maps proposal.

[MylesBorins]

Minimal kernel imho:

• No transparent interop
• import only supports ESM
  • no json
  • no common
  • no native modules
  • perhaps explicit ban on .js extension for now
• No extension or folder searching (move modules: remove file extension and directory resolving for esm node#21729 to the fork and iterate)
  • support for node_modules?
• createRequireFunction to allow for cjs in esm interop (move module: add createRequireFunction method node#19360 to the fork and iterate)
• dynamic import to allow for esm in cjs interop

[devsnek]

i would still say that any situation where we land without node resolution enabled by default is unworkable, and so it should be part of the kernel.

[MylesBorins]

@devsnek I don't agree with you, and thus we don't have consensus. We can't remove it later and thus I think it shouldn't be in the kernel

[giltayar]

@MylesBorins - I'm assuming your minimal kernel also doesn't assume an extension, and the extension has to be explicitly in the name?