Node.js module changes

[benjamingr]

Hey,

Node.js is debating some changes with regards to modules and we'd like your help.

The changes are outlined here: nodejs/TSC#1445 (comment)
The migration path for package authors is outlined here: nodejs/TSC#1445 (comment)

What we'd hopefully like is:

• For npm publish to warn if the published package.json file does not have a "type" field.
• For npm init to set "type": "module" in "new" Node.js by default.

This is still all in discussion in Node.js, the above list is just some ideas and this issue is mostly so we can discuss things.

[wraithgar]

This is best discussed in https://github.com/npm/rfcs

[GeoffreyBooth]

@wraithgar This landed in Node and was released in 21.1.0:

• esm: detect ESM syntax in ambiguous JavaScript nodejs/node#50096

We hope to make this enabled by default, without requiring a flag, in a future version of Node (potentially as soon as Node 22 in April 2024). This will mean that any Node app and dependency without a package.json type field will have a slower startup time. Therefore we would appreciate any help that npm can provide in ensuring that both application developers and library authors add a type field to every package.json file, even if it’s just making explicit the default "type": "commonjs". I agree with @benjamingr’s suggested improvements above.

This is best discussed in npm/rfcs

npm/rfcs#620 is already open, which suggests one of these changes. Perhaps now that this performance penalty to type-less packages is potentially coming to Node, it might be timely to act on that proposal?

[wraithgar]

We can get this into the init-package-json roadmap but there is no way to edit any already published package so the vast majority of packages in the ecosystem just got slower load times.

[GeoffreyBooth]

More specifically, packages that don't currently include a type field or use .mjs/.cjs get slightly lower load times. Which is many of them, for sure; but all they need to do is add "type": "commonjs" and the penalty disappears. Yes this doesn't help unmaintained packages or transitive dependencies of old packages, etc, but that's the trade-off we've chosen.

[ljharb]

… which is the vast majority of packages, for the foreseeable future.

[GeoffreyBooth]

@wraithgar FYI this has been backported and released in Node 20.10.0: https://nodejs.org/en/blog/release/v20.10.0