Import file specifier proposal implementation

[GeoffreyBooth]

Hi folks,

In the last two meetings I asked the group for any additional notes on the import file specifier proposal, and I haven’t received any. I hope that means we should be ready to merge in @guybedford’s implementation of it. That’s in a PR here: nodejs/ecmascript-modules#28.

This PR does not include the package exports proposal, as there’s ongoing discussion regarding whether that proposal should cover CommonJS. So instead of using "exports" as the “package.json ESM-signifying field” that the import file specifier looks for, this branch looks for "type": "esm" per this proposal. This is temporary; the shape of the package.json configuration is expected to change when the package exports implementation is merged in, and likely again when support for loaders is added, at the least. I encourage the group to allow merging in this PR as is, with the understanding that the package.json UX will change in the future. Also note that Phase 4 is intended for user feedback and UX revisions.

Relative to the current “minimal kernel” new implementation, this PR adds support for:

• import of either ESM or CommonJS bare specifiers: import 'lodash', including supporting "main" for ESM packages.

• Deep import of files within either ESM of CommonJS packages: import shuffle from 'lodash/lib/shuffle.mjs'.

• import of .js files as ESM within ESM-designated package scopes: import './startup.js'.

• Initial entry point of a .js file within an ESM package scope: node app.js.

The “package scope” concept, support for .js as ESM within ESM package scopes, and CommonJS interoperability are all important features that I’d like to get merged into our new implementation sooner than later so that other features (such as loaders) can build upon them. I would encourage people to consider if any objections they have to this PR might be acceptably addressed in follow-up PRs rather than blocking this one, so that we can continue our progress toward trying to release the new implementation either flagged or unflagged by April.

[ljharb]

The only part of this that concerns me is the "ESM mode" part (no matter how temporary, or what the current API is). Can we land the rest of it in the fork more quickly, and try to land that part separately?

[GeoffreyBooth]

Can we land the rest of it in the fork more quickly, and try to land that part separately?

Not really, the proposal really needs the ESM signifying field in package.json in order to work. Like I wrote, though, the specific configuration is very likely to change as the work progresses. Anything in package.json should be considered very work-in-progress until we’re deep into Stage 4.

[MylesBorins]

is there more to do with this?

[GeoffreyBooth]

Nope, this was added in nodejs/ecmascript-modules#28