[FEATURE] prompt for module type as part of npm init

[thescientist13]

What / Why

As part of npm init, the script should prompt the user for a module type for the project's package.json, with a default value of commonjs if nothing is selected.

This would be helpful for the tooling / loader / JS ecosystem in terms of better understanding package contents by making sure this setting is always available (and not needing to know the assumed default workings of npm / nodejs / etc)

When

When a user runs npm init

Where

NPM CLI

How

Current Behavior

By default, npm init (and accepting all defaults) creates a minimal package.json like this

$ npm init
$ cat package.json
{
  "name": "scratch",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC"
}

Expected Behavior

After running npm init the user should be prompted to provide a module type, with the default being commonjs

$ npm init
.
.
type: (commonjs)
  - commonjs
  - esm
  - others?  (amd, umd...?)
.
. 
$ cat package.json
{
  "name": "scratch",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "type": "commonjs",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC"
}

Who

References

Discussed during Node+JS Interactive 2019 Collab Summit during the ESM modules session.

[ljharb]

I'm concerned about users choosing "module", however, and unwittingly not being backwards compatible with older nodes and browsers.

It seems like the first question npm init should be asking is "is this an app or a package", and having that inform the choice?

Either way, adding "type: commonjs" by default seems like a great improvement.

[thescientist13]

It seems like the first question npm init should be asking is "is this an app or a package", and having that inform the choice?

Good point. Making sure to ask / present the prompt in an easily understandable way and the implications of the answer to that question, is definitely good to call out. In general, there is definitely a level of awareness to the broader community at large, and in a way this feature could be a good way to start spreading that awareness.

Maybe it could include a link to learn more about what each type means and the use cases for it, to better help better support developers as they make that decision? (and from that, where would that link live, npmjs or Node+JS website, or other?)

[wesleytodd]

IMO, the first step is not even asking and just adding "type": "commonjs" as @ljharb mentioned. I am not sure how complicated npm init should be by default because the decisions on some of these things are complicated and maybe not obvious for a newbee. Since npm init is really the first thing a new package author would do, it probably shouldn't be too fancy to start. Without explaining the pitfalls (today and hopefully temporary) of ESM in node it would be painful for new authors to even have that choice without fully understanding.

[thescientist13]

Fair points re: prompt vs default.

That said, (and I can go through npm init some more) but is there anything npm init sets that isn't asked of the user first though? Just curious if the convention is that all things that npm init generates are / should be presented to the user.

I am also happy to rephrase (or maybe open a new one?) the RFC to remove prompt entirely and the behavior can be to just set the module type all the time. Not sure if the npm team has any strong preferences here as well.

[wesleytodd]

Yes right now the only things included are also prompted for. Maybe it is fine to prompt and set the default to commonjs. I just worry that the pitfalls are still not widely known, and so many people have a false belief that what they do with webpack will work for everyone with node could lead to many broken modules.

[thescientist13]

I suppose one line of thinking here was that if education is needed / desired to help spread awareness around the community of this topic, this prompt could be a good way to start new packages off on the right step and also engage the community to be aware / informed of the options.

I suppose it may come down to if the NodeJS community itself has a strong and compelling story itself to tell around this topic and what sort of narrative it feels should be spread across the ecosystem (say it loud, need to know, etc). Though I can understand wanting to refrain from jumping to one choice too soon, as it could have a negative effect as well.

So it seems that although we all agree here on a default type, how it gets into package.json is the key (no pun intended 😄 ):

1. Prompt to the user
2. Add it as default, and let the user change it when they need to for the benefit of their package

(Or maybe there's a third option?)

[mikemimik]

I'm of the mind that the first pass at this should just be to set a default value. When you run npm init the resulting package.json will just have "type": "commonjs" to begin with. At the moment that module hasn't seen love in quite some time, so doing anything else as a first pass might constitute more work that we want to invest right away.

Ideally, though, all values in should be prompted for.

I'm not sure the default npm init logic should handle educating the end user though. Currently there is a prompt for licensing and end users tend to know very little about this. An argument could be made that if we're going to educate about the one, we should educate about the other. However, this then opens up the conversation and scope far to wide, I think.

I'd be curious to know if most people run npm init or npm init -y; skipping all prompts anyways.

[ljharb]

I never use -y; its defaults are always incorrect for me (starting at 1.0.0 instead of 0.0.0 so i can’t bump the version to 1.0.0 in the release commit; defaulting the package name to the folder name which for me always ends in .git, defaulting the license to ISC instead of MIT, etc)

I think that npm init absolutely should be educating users if it has the opportunity.

[thescientist13]

It seems then that if we want to be consistent with how things work currently, it should be that the user gets prompted. Unless we are looking to make an exception because of where the state of modules is in NodeJS? Would / could this set precedent for this to happen with other default values, and is that a precedent we would want to open the door to?

It seems that there could be a whole other RFC to discuss if a choice presented to a user during npm init should also include a link for the user to have as a reference in the event they would like to know more. I think the case of licensing makes just as much of a compelling argument for this kind of enhancement. I would definitely be willing to opening an RFC for this if others think it is worth the discussion.

[thescientist13]

Looks like this has been (re) submitted as an RFC - #347