[RRFC] npm init add a new question: type => "commonjs/module"

[aladdin-add]

Motivation ("The Why")

As more devs are going to use esm, while the default is commonjs. users have to manually add the field after creating.

Example

How

Current Behaviour

package name: (xxx) 
version: (1.0.0) 
description: 
entry point: (index.js) 
test command: 
git repository: 
keywords: 
license: (ISC) 

Desired Behaviour

package name: (xxx) 
version: (1.0.0) 
description: 
type: commonjs/module  ----- new added item.
entry point: (index.js) 
test command: 
git repository: 
keywords: 
license: (ISC) 

References

• n/a

[ruyadorno]

For reference, today we need an extra step to get there, e.g:

$ npm init -y
$ npm pkg set type=module

[ljharb]

I think this is a very bad idea. "type: module" isn't needed for anyone, and actively disrupts many tools that haven't been updated to handle it.

[thescientist13]

For historical context, this has come up before recently ( #75 / #347 ) and it was decided to leave init the way it is for now.

---

Though for something like this, it can't hurt to reevaluate it routinely as / if the ecosystem eventually shifts to the new format by default, but in only a year passing since of #347 , I think the lens of this is probably more in 5 year increments, as opposed to yearly increments, but anything can happen!

I would personally be in favor of having the prompt, even if the default is commonjs but understand that it might not make sense to touch things until there is a meaningful need.

Just my $.02.

[ljharb]

It's also very unclear if the ecosystem will ever shift to "type module" by default, even IF it shifts to ESM by default (which is also very unclear if it will ever happen).

The default type of "commonjs" works just fine with ESM, and ESM packages should be sticking with that as well, and using .mjs for ESM files.

[jeffschwartz]

How about:
npm init -y --type-module

[ThePlenkov]

Supporting your idea @jeffschwartz why not to think then of all npm config parameters during init making it perfect for use in CI and other dev scripts:

npm init -y --name=@myorg/component  --type=module --private=true --workspaces=["packages/*"] --license=MIT

So bascially we can use same format as for npm pkg set

This would also cover following RFCs
#597
#579

[jeffschwartz]

I would like to use the following in support of my suggestion, though my suggestion has now been modified to add `"type": "commonjs" when initializing package.json. Please bear with me.

Point 1) The official documentation (https://nodejs.org/dist/latest-v18.x/docs/api/packages.html#type) states that:

• The "type" field defines the module format that Node.js uses for all .js files that have that package.json file as their nearest parent.
• If the nearest parent package.json lacks a "type" field, or contains "type": "commonjs", .js files are treated as [CommonJS](https://nodejs.org/dist/latest-v18.x/docs/api/modules.html). If the volume root is reached and no package.json is found, .js files are treated as CommonJS.

Point 2) The official documentation (https://nodejs.org/dist/latest-v18.x/docs/api/esm.html#enabling) also states that:

• Node.js has two module systems: CommonJS modules and ECMAScript modules.
• Authors can tell Node.js to use the ECMAScript modules loader via the .mjs file extension, the package.json "type" field, or the --input-type flag. Outside of those cases, Node.js will use the CommonJS module loader. See Determining module system for more details.

Point 3) From the above documentation we find that both CommonJS modules and ECMAScript modules are supported and that Common.JS is the default unless otherwise specified via "type": "module".

Since, as stated, CommonJS is the default but ECMAScript modules are an option, why not make that explicitly clear by including `"type": "commonjs" when initializing package.json.

[ljharb]

the default for .js files. .mjs files are always ESM, and the type field confused people about this point. iow, ESM isn’t just an option, it’s always available.

[jeffschwartz]

Hi @ljharb. Was your comment in response to mine?

[ljharb]

Yes, to the last paragraph of your comment.

[jeffschwartz]

Thanks @ljharb . I understand. To this, then:

Since, as stated, CommonJS is the default but ECMAScript modules are an option, why not make that explicitly clear by including "type": "commonjs" when initializing package.json.`

That is just an acknowledgement of what the official docs say. I'm not sure if you are taking exception to that or are agreeing with that.

[ljharb]

If the official docs say that, then they're wrong; ESM is an option, but so is CJS - neither is "the default".

[jeffschwartz]

Thanks again, @ljharb. Going by context alone I would disagree with you that the docs are wrong and as for having defaults for options, why is is that wrong? That's extremely common, isn't it?

[ljharb]

The default value of the ”type” field is of course the string “commonjs” :-) but there is no default module system nor a configuration option to choose one - both module systems are always available.

[jeffschwartz]

Yes, @ljharb, that is true and therefore, being that is the case, then -- I'm now readjusting my position again :) - why not include the question when nvim init is run and default to commonjs when it is run with the -y option. Question for you, is package.json with comments supported? If it is then why not add it to package.json but leave it commented out and leave it up to the user to then uncomment it if needed and set its value appropriately in regard to their project?

Anyway, @ljharb , it is a really nice experience having this discussion with you. I wish all my open source interactions were this pleasant lol.

I will be very curious as to what the final outcome of this is. NPM is such an awesome tool and my gosh, I want to thank all its maintainers including you, of course, for the marvelous job you continue to do. I think I speak for the rest of the community as well or at least I should hope so :).

[ljharb]

No, JSON doesn’t have comments in the way you mean. Since there’s no benefit in changing the default of “type”, i think it would be actively harmful to include it by default. The best outcome is if nobody specifies it, and ESM is confined to .mjs files.

[jeffschwartz]

Numerous json configurations now support comments directly in .json files.

[ljharb]

That’s not JSON then, that’s something like JSON5. The only comments JSON has are duplicating a key, so the first one is the comment and the last one is the value.

[jeffschwartz]

Depends on what you mean by "like".