-
Notifications
You must be signed in to change notification settings - Fork 18
Conversation
is this trumped by #29? |
This is the PR seeking consensus. #29 is the addon given dynamic modules, but we still don't know what the status of dynamic modules is right now. |
This corresponds with nodejs/modules#256. If the group wants to merge in this and dynamic modules, then we could merge #29 instead; but we’re assuming there’s at least a good chance that there won’t be appetite just yet for dynamic modules, so we’re hoping that this PR (without dynamic modules) can get merged in at least. |
I will not be able to attend any meeting today since TC39 is going on, but would like to express support for this PR if there is not quorum in a meeting. If such a meeting takes place, consider myself to be a +1. |
I'll try to attend but may not be able to for the same reason; I object to |
As a note before the meeting so this isn't a surprise... If we cannot get named exports for CJS modules I am not in support of the IRP proposal.. specifically at this point I am not sure we should be shipping any interop without named exports. It appears, and I could be wrong, that if we will not be shipping interop that there is not a need for this proposal. Thoughts? |
Thanks @targos for the review, I've integrated those changes. |
I think without CommonJS interoperability there’s still definitely a need for this proposal, though obviously not the parts of it that concern |
Per @MylesBorins in the meeting today, this will be merged in Wednesday, Feb. 6 unless there are objections. If you have objections, please note them before Feb. 6 so that they can be addressed before the next meeting on Wednesday, Feb. 13. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
surfacing my objection here: #28 (comment)
@ljharb can't we agree that a mechanism should exist and that when it exists it will be mutually exclusive with this flag (and that this flag should be an alias for some kind of other more verbose configuration), but defer specifying it? Having to do that means getting into the weeds about pluggable loaders and mimes and a whole boatload of stuff that by and large doesn't matter for what we really want to solve with this flag. |
@ljharb I’m happy to support a Can we move forward without such a field for now and add it later once someone has done the work to design and implement it? |
My concern is, what happens if we can never figure that out? Then we'd be stuck with Also, how can we make it mutually exclusive now if we don't know the final name for the generic mechanism's package.json field? |
My understanding of loaders is that they will certainly be able to control Node’s handling of file extensions, for example by sending |
I'm concerned with being able to specify it in package.json so that loaders can infer the only actually safe and reliable means of determining this: the author's intention. Otherwise, a (non-per-packaeg) loader has to unsafely make a choice for code that the person configuring the loader didn't author. |
Currently |
I think that privileging one remapping ( |
I think privileging that one remapping is expressly what we're trying to do - we're expressly responding to the community's adverse reaction to not being able to have esm in |
Fair point. I'll think about that between now and the 6th, including thinking about a possible design for the more granular case. |
For what it’s worth, Currently all Node is doing with that piece of metadata is mapping |
The algorithm to resolve an ES module specifier is provided through | ||
_ESM_RESOLVE_: | ||
The algorithm to load an ES module specifier is given through the | ||
**ESM_RESOLVE** method below. It returns the resolved URL for a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prolly should tweak any "URL" reference to "File URL".
@GeoffreyBooth right, but "an X package" is not the same thing as "a package that parses |
Node isn’t the only consumer of NPM packages: they’re also used by bundlers, for example. Having neutral metadata describing a package is different than something like a The file extension |
Refs: nodejs/modules#180 Refs: #6 Refs: #12 Refs: #28 Refs: https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal Co-authored-by: Myles Borins <[email protected]> Co-authored-by: John-David Dalton <[email protected]>
Refs: https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal Refs: nodejs/modules#180 Refs: #6 Refs: #12 Refs: #28 Co-authored-by: Myles Borins <[email protected]> Co-authored-by: John-David Dalton <[email protected]>
Refs: https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal Refs: nodejs/modules#180 Refs: #6 Refs: #12 Refs: #28 Co-authored-by: Myles Borins <[email protected]> Co-authored-by: John-David Dalton <[email protected]>
Refs: https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal Refs: nodejs/modules#180 Refs: #6 Refs: #12 Refs: #28 Co-authored-by: Myles Borins <[email protected]> Co-authored-by: John-David Dalton <[email protected]>
Refs: https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal Refs: nodejs/modules#180 Refs: #6 Refs: #12 Refs: #28 Co-authored-by: Myles Borins <[email protected]> Co-authored-by: John-David Dalton <[email protected]>
Refs: https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal Refs: nodejs/modules#180 Refs: #6 Refs: #12 Refs: #28 Co-authored-by: Myles Borins <[email protected]> Co-authored-by: John-David Dalton <[email protected]>
Refs: https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal Refs: nodejs/modules#180 Refs: #6 Refs: #12 Refs: #28 Co-authored-by: Myles Borins <[email protected]> Co-authored-by: John-David Dalton <[email protected]>
Refs: https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal Refs: nodejs/modules#180 Refs: #6 Refs: #12 Refs: #28 Co-authored-by: Myles Borins <[email protected]> Co-authored-by: John-David Dalton <[email protected]>
Refs: https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal Refs: nodejs/modules#180 Refs: #6 Refs: #12 Refs: #28 Co-authored-by: Myles Borins <[email protected]> Co-authored-by: John-David Dalton <[email protected]>
Refs: https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal Refs: nodejs/modules#180 Refs: #6 Refs: #12 Refs: #28 Co-authored-by: Myles Borins <[email protected]> Co-authored-by: John-David Dalton <[email protected]>
Refs: https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal Refs: nodejs/modules#180 Refs: #6 Refs: #12 Refs: #28 Co-authored-by: Myles Borins <[email protected]> Co-authored-by: John-David Dalton <[email protected]>
Refs: https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal Refs: nodejs/modules#180 Refs: #6 Refs: #12 Refs: #28 Co-authored-by: Myles Borins <[email protected]> Co-authored-by: John-David Dalton <[email protected]>
Refs: https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal Refs: nodejs/modules#180 Refs: #6 Refs: #12 Refs: #28 Co-authored-by: Myles Borins <[email protected]> Co-authored-by: John-David Dalton <[email protected]>
Refs: https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal Refs: nodejs/modules#180 Refs: #6 Refs: #12 Refs: #28 Co-authored-by: Myles Borins <[email protected]> Co-authored-by: John-David Dalton <[email protected]>
Refs: https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal Refs: nodejs/modules#180 Refs: #6 Refs: #12 Refs: #28 Co-authored-by: Myles Borins <[email protected]> Co-authored-by: John-David Dalton <[email protected]>
This PR updates the current `--experimental-modules` implementation based on the work of the modules team and reflects Phase 2 of our new modules plan. The largest differences from the current implementation include * `packge.type` which can be either `module` or `commonjs` - `type: "commonjs"`: - `.js` is parsed as commonjs - default for entry point without an extension is commonjs - `type: "module"`: - `.js` is parsed as esm - does not support loading JSON or Native Module by default - default for entry point without an extension is esm * `--entry-type=[mode]` - allows you set the type on entry point. * A new file extension `.cjs`. - this is specifically to support importing commonjs in the `module` mode. - this is only in the esm loader, the commonjs loader remains untouched, but the extension will work in the old loader if you use the full file path. * `--es-module-specifier-resolution=[type]` - options are `explicit` (default) and `node` - by default our loader will not allow for optional extensions in the import, the path for a module must include the extension if there is one - by default our loader will not allow for importing directories that have an index file - developers can use `--es-module-specifier-resolution=node` to enable the commonjs specifier resolution algorithm - This is not a “feature” but rather an implementation for experimentation. It is expected to change before the flag is removed * `--experimental-json-loader` - the only way to import json when `"type": "module"` - when enable all `import 'thing.json'` will go through the experimental loader independent of mode - based on whatwg/html#4315 * You can use `package.main` to set an entry point for a module - the file extensions used in main will be resolved based on the `type` of the module Refs: https://github.com/nodejs/modules/blob/master/doc/plan-for-new-modules-implementation.md Refs: https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal Refs: nodejs/modules#180 Refs: nodejs/ecmascript-modules#6 Refs: nodejs/ecmascript-modules#12 Refs: nodejs/ecmascript-modules#28 Refs: nodejs/modules#255 Refs: whatwg/html#4315 Refs: WICG/webcomponents#770 Co-authored-by: Myles Borins <[email protected]> Co-authored-by: John-David Dalton <[email protected]> Co-authored-by: Evan Plaice <[email protected]> Co-authored-by: Geoffrey Booth <[email protected]> Co-authored-by: Michaël Zasso <[email protected]> PR-URL: nodejs#26745 Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Ben Coe <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Сковорода Никита Андреевич <[email protected]>
This PR updates the current `--experimental-modules` implementation based on the work of the modules team and reflects Phase 2 of our new modules plan. The largest differences from the current implementation include * `packge.type` which can be either `module` or `commonjs` - `type: "commonjs"`: - `.js` is parsed as commonjs - default for entry point without an extension is commonjs - `type: "module"`: - `.js` is parsed as esm - does not support loading JSON or Native Module by default - default for entry point without an extension is esm * `--entry-type=[mode]` - allows you set the type on entry point. * A new file extension `.cjs`. - this is specifically to support importing commonjs in the `module` mode. - this is only in the esm loader, the commonjs loader remains untouched, but the extension will work in the old loader if you use the full file path. * `--es-module-specifier-resolution=[type]` - options are `explicit` (default) and `node` - by default our loader will not allow for optional extensions in the import, the path for a module must include the extension if there is one - by default our loader will not allow for importing directories that have an index file - developers can use `--es-module-specifier-resolution=node` to enable the commonjs specifier resolution algorithm - This is not a “feature” but rather an implementation for experimentation. It is expected to change before the flag is removed * `--experimental-json-loader` - the only way to import json when `"type": "module"` - when enable all `import 'thing.json'` will go through the experimental loader independent of mode - based on whatwg/html#4315 * You can use `package.main` to set an entry point for a module - the file extensions used in main will be resolved based on the `type` of the module Refs: https://github.com/nodejs/modules/blob/master/doc/plan-for-new-modules-implementation.md Refs: https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal Refs: nodejs/modules#180 Refs: nodejs/ecmascript-modules#6 Refs: nodejs/ecmascript-modules#12 Refs: nodejs/ecmascript-modules#28 Refs: nodejs/modules#255 Refs: whatwg/html#4315 Refs: WICG/webcomponents#770 Co-authored-by: Myles Borins <[email protected]> Co-authored-by: John-David Dalton <[email protected]> Co-authored-by: Evan Plaice <[email protected]> Co-authored-by: Geoffrey Booth <[email protected]> Co-authored-by: Michaël Zasso <[email protected]> PR-URL: #26745 Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Ben Coe <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Сковорода Никита Андреевич <[email protected]>
This PR includes the specification and implementation work for:
The implementation is exactly in sync with the specification diff here, and provided as separate commits.