Make "npm init" generate a stub package.json that includes "type":"module"

[Pomax]

It's late 2023, ESM has huge adoption, and so it would be nice if npm init added "type": "module" to the package.json it generates by default instead of requiring folks to put that in themselves despite that being the official JS module system for quite some time now. Rather that putting the burden on folks who want to use modern JS, it would at this point in time make more sense to generate an ESM project when folks run the init command, and move the burden of removing that for CJS onto folks who want to create new projects but for some reason still want that to use the legacy CJS system.

[ljharb]

Elaborate on “huge”?

type module is simply not required - or even advisable - to use native ESM, so there’s no burden here.

Duplicate of #75.

Also, CJS isn’t “legacy”, isn’t ever going away, and will be present in most applications for the foreseeable future.

[Pomax]

Elaborate on “huge”?

I feel like no answer you're going to get is going to convince you of its adoption if your view is that CJS is not a legacy system.

CJS was invented to overcome the lack of modules in JS, it was a Node-specific solution to a real problem with the JS language that got an official language level solution quite a few years ago now (and that Node's has supported since V14) and that the Node ecosystem should at this point in time be promoting as the proper way to write JS imports and exports, with CJS being deprioritized. It's a legacy solution from an era that we're no longer in. Lots of code uses it, but there is zero reason to perpetuate it as "the main way new projects do modules". Keeping up with JS is a worthwhile effort, one that Node and its tooling, including NPM, have a pretty good track record of these days.

type module is simply not required - or even advisable - to use native ESM

this is... not true? Node will error out if you run JS with ESM import/exports without either the type indicator in package.json, which it should be adding as default these days (people who want CJS know they want CJS, and can either say "no" during init, or they can delete the type indicator, not that much work: every single person who wants to use normal ESM currently has to do the reverse of that), or by using the crux mjs extension, which we came up with only because we couldn't quite figure out how to cleanly work with mixed module types using just the regular JS extension back when ESM was specced out and got its first implementations.

[ljharb]

and that the Node ecosystem should at this point in time be promoting as the proper way to write JS imports and exports, with CJS being deprioritized.

this is the opinion of some, but is not a consensus opinion of node.

The .mjs extension isn't "crux" (and i think you mean "cruft"), it was created because Script and Module are ambiguous parse goals, and the entire point of file extensions since the inception of files is to tell you how to parse the contents. ESM should be .mjs.

[wesleytodd]

not a consensus opinion of node.

To add on this a bit, it doesn't even matter if it is the consensus opinion of node, the setup for having a good end UX today for both ESM and CJS consumers is one of two things:

1. a complicated setup and toolchain to dual publish
2. publish CJS

As long as that is the case I don't think there is incentives for module authors to move, although obviously some want it and have moved, but that is not the majority.

[Pomax]

this is objectively not true, but we seem to have lost the historical perspective on why we needed those complicated setups in the first place. There was no module system, requirejs and jquery were our best options, and Node didn't even exist. Then Node showed up, introduced CJS, and browserify got invented, followed by webpack, then rollup tried the ESM thing, and these days the best bundler is esbuild (because it's a JS bundler not written in JS, which took us long enough to figure out). And instead of going "wait... do we even need bundling still?", which we don't, people kept going "you need a complicated setup and toolchain to build for Node and the browser".

Because you really don't: both Node and the browser have full, native support for ESM now; Node never needed bundling to begin with, and browsers haven't really needed bundling since Edge got introduced with <script type="module"> support, and we definitely haven't needed bundling ever since IE was (thank the lord, finally) killed off by Microsoft in mid-2022.

Times change. JS changes even faster. People, however, seem to not want to. CJS was a crux from an era when we needed something and CJS was the best we could come up with (and it was good). In 2023 coming up to 2024, it is simply another grunt, or gulp, or any other solution we needed in the past but no longer need.

[ljharb]

Browsers still need bundling, because ESM is slower than bundles by design due to its inherent waterfall network-loading design.

(again, the word is "cruft", which means badly designed etc, not "crux", which means the most important point of an issue).

You can claim CJS is something we no longer need only if you ignore the largest package repository on the planet in any language which is composed almost entirely of CJS.

[wesleytodd]

It was a while ago, but the npm team had agreed that moving these opinions out of npm and into a third party module was a better path forward. That module exists: https://github.com/pkgjs/create-package-json/

Additionally, the package maintenance working group in collaboration with @darcyclarke (former npm team manager) had plans to build pkg which would scaffold a whole starter package based on best practices from the PMWG. That is here but is not complete. The high level goal was to make sure it did the basics, but was easily composable so that others can ship their own opinions. So if you wanted to you could start using the create-package-json package today, and it does support type: module

[Pomax]

@wesleytodd good to know!