You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 2, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Sep 2, 2023. It is now read-only.
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.
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?
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>
.
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>
> .
>
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.jsonmain 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.
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.
edit: to be explicit this is not something that would ever be shipping. The purpose of this kernel is to build a subset implementation that can be used to implement all features we are currently debating to allow pull requests for specific features or full proposals to build on top of the same code base (and likely share more code)
what is a minimal implementation
both browser + node need bare imports
implementation to be discussed
we cannot have dynamic path searching
requiring the full path is an issue for tooling and a long term solution is required
migration strategies also have issue with this
common.js backwards compat
createRequireFunction does
import.meta.require does not fail early enough
hold off on importing common.js until more progress is made on dynamic modules spec
.mjs will be the only way to import ESM
intention is to move forward with format databases to map extensions and support multiple use cases
only supporting importing ESM
no JSON
no native modules
createRequireFunction used to get these
will come back with format database
Steps to get there
removing importing of formats other than ESM
no common.js
no JSON
no nativemodules
removing of dynamic path searching
no extension adding
no directory resolution
no support for index.js
still maintaining support for the main field
adding createRequireFunction
Reacted by Sendil Kumar N, Michael Ciniawsky, Jan Potoms, Saleh Abdel Motaal and Evan Plaice
@michael-ciniawsky I think the intent was to support package.main as a means to specify the entry point of a module, and that this path would need to be explicit (no path searching).
We were debating if this should even be supported, perhaps it should be dropped.
Activity
MylesBorins commentedon Aug 14, 2018
what would we want to call the fork? node-esm?
devsnek commentedon Aug 14, 2018
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 commentedon Aug 15, 2018
GeoffreyBooth commentedon Aug 15, 2018
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 commentedon Aug 15, 2018
giltayar commentedon Aug 15, 2018
giltayar commentedon Aug 15, 2018
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:
importan ESM either withimport fromin an ESM file, or using dynamicimportfrom a CJS or ESMAvoiding the "file extension debate"
importwill not guess the file extension and will import the file as ESM:import ... from './foo.js'orimport ... from './foo.mjs'will both import an ESM from the corresponding files because the extensions have no meaning. It could be./foo.foofor 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.package.jsonmainproperty and will load that as ESM. Again, will not guess the file extension.index.jsbecause that will provoke a "file extension debate", and we all want to evade that.node_modulesin parent dir...), except that it will not look forindex.js(orindex.mjs).Avoiding the "transparent interop debate"
importan ESM, because that is in the JS spec, and is mostly a consensus in the group (I hope...).requirea CJS file.import.meta.requirePR to enable this, as this is easily removable later if another interop mechanism is chosen.That's it.
devsnek commentedon Aug 15, 2018
node looks for index.{any registered file extension} atm, will we still support that with your proposal?
GeoffreyBooth commentedon Aug 15, 2018
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
requirealgorithm or the package name maps proposal.MylesBorins commentedon Aug 15, 2018
Minimal kernel imho:
devsnek commentedon Aug 15, 2018
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 commentedon Aug 15, 2018
@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 commentedon Aug 15, 2018
@MylesBorins - I'm assuming your minimal kernel also doesn't assume an extension, and the extension has to be explicitly in the name?
MylesBorins commentedon Aug 15, 2018
@giltayar indeed
3 remaining items
MylesBorins commentedon Sep 12, 2018
edit: to be explicit this is not something that would ever be shipping. The purpose of this kernel is to build a subset implementation that can be used to implement all features we are currently debating to allow pull requests for specific features or full proposals to build on top of the same code base (and likely share more code)
what is a minimal implementation
Steps to get there
michael-ciniawsky commentedon Sep 12, 2018
pkg.module? Or willpkg.mainstill lookup the file extension (as an exception)? This feels inconsistent/confusing if paths searching is removed...package.jsonpackage.json?
MylesBorins commentedon Sep 12, 2018
@michael-ciniawsky I think the intent was to support
package.mainas a means to specify the entry point of a module, and that this path would need to be explicit (no path searching).We were debating if this should even be supported, perhaps it should be dropped.
MylesBorins commentedon Sep 12, 2018
here's a doc so people can comment and offer suggestions for changes. If you would like to suggest alternative proposals please do so in the issue
https://docs.google.com/document/d/1uq3v1h3dUXmjMAabQCsxdj7Ig2lOpaty1u4HcUi8whQ/edit?usp=sharingmichael-ciniawsky commentedon Sep 12, 2018
So no 'dual-mode' packages (for now) ?
MylesBorins commentedon Sep 12, 2018
indeed. It is something that would be part of a future enhancement to the kernel, dependent on the feature set
doc: first pass at minimal-kernel
MylesBorins commentedon Sep 12, 2018
I've opened a PR to add documentation about our minimal kernel to the repo. Please comment / approve / reject in there rather than the google doc #180
doc: first pass at minimal-kernel
doc: first pass at minimal-kernel
MylesBorins commentedon Sep 25, 2018
We have a PR open to solve this, going to close the issue
doc: first pass at minimal-kernel (#180)