The `--init-type` flag should default to `module`

[jonkoops]

The changes from #8081 introduced a new --init-type flag that sets the field type to commonjs by default, or any user provided string value. This is a good start but has a couple of caveats, namely:

• The default value of commonjs is not suitable for new packages, ideally this would default to module as the whole ecosystem is moving to ECMAScript modules, this is especially true for new packages.
• There are only two valid options for the type field (commonjs or module), and this field allows free input of text by the user, ideally the user would select from these predefined options only.

[wraithgar]

The decision to allow free input was intentional to future proof this against any other possible values there. npm itself does not control that entry, so we opted to be permissive there.

The default was because anything else would be a breaking change. Folks typing npm init -y would now all of a sudden be generating different packages than before.

The default value of commonjs is not suitable for new packages

This is very much an opinion, and one that was discussed at length in Node.js. Again, Node.js is in the driver's seat here, not npm. npm will follow Node.js's defaulting here, if the default changes we can change our default in a future npm major release.

[jonkoops]

The decision to allow free input was intentional to future proof this against any other possible values there. npm itself does not control that entry, so we opted to be permissive there.

Is there any reason to believe there will be new values introduced here? If like you mentioned later on the idea is to follow Node.js conventions as much as possible, then it seems that is a finite set of options. Selecting from a list of predefined options would be a much better DX for generating a new package.

The default was because anything else would be a breaking change. Folks typing npm init -y would now all of a sudden be generating different packages than before.

Is this something that should have an expectation of being a breaking change? I can't really see a scenario where this would be generated en masse in any sort of automated process, it would be much more likely developers would generate their own JSON from any automated tooling. Even if it would be a breaking change, what prevents us from making this change in the next major version?

I don't believe the discussion you have linked here from the Node.js team actually passes any final judgement on new packages, it mostly about what the default behavior should be in Node.js if this information should be in the package is not present for existing projects. Additionally, this discussion is quite old and does not take recent developments around interoperability and module detection into account.

Any comments around the default type when initializing a new package seem to revolve around compatibility issues that largely no longer exist thanks to @joyeecheung's work on interoperability, especially when Node.js 18 becomes end-of-life in April, which is the last supported version of Node.js that does not carry all the necessary patches.

I believe this is a chance to provide a more logical default to new users that might not be familiar with the variety of module systems in the Node.js ecosystem, and arguably ECMAScript modules are a much more sensible starting point considering it is the language standard and omnipresent in every part of the ecosystem.

I hope it will be considered to re-open this issue, as I honestly believe this is something that should be properly discussed and reevaluated at this point.

[mhdawson]

@wraithgar would it be possible to have two options to choose from, along with free entry, with the default currently being commonjs, I see value in helping avoid mistyping the two most common possiblities.

[mikemaccana]

@wraithgar hah I was just talking about this with the node people - back in November Node thought it's in npms hands, while (as you wrote above) npm think's it's in node's hands!

Node.js is in the driver's seat here, not npm. npm will follow Node.js's defaulting here, if the default changes we can change our default in a future npm major release.

Node discussed this in at the Node Collaboration Summit in Nov 2024 "Module loading customization/optimization and CJS/ESM interoperability" - specifically, since the npm command is out of their hands, they were talking about node --init (yes node --init).

Check out node --init duiscussion.

However if npm is following node's defaulting, then it seems reasonable to have npm --init default to ESM on the next major release. There's seems to be quite a high demand for ES6 defaults.

@wraithgar considering node also want to default to ESM, could this issue please be reopened?

[joyeecheung]

FWIW whatever discussed at a collaboration summit should be considered non-binding brainstorming from a small subset of Node.js contributors who are able to go there. Collaboration summits are never meant to make decisions, and it's wrong to use them to do that without going back to GitHub for including people not going to the summit. There is no formal decision about actually replacing npm init with node --init and the flag is not even implemented yet AFAICT. The blog post even put it very clearly there

WARNING: This is a proposal and not yet implemented. Also, it's may never be implemented. Please don't take this for granted.

The only way to confirm "this is what node wants" is to open an issue in nodejs/node or send in PRs and get it properly discussed there asynchronously. Until that's merged with no outstanding objections and released it can't really be said that "this is what node wants".