[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.