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.