Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RRFC] Add type to npm init #347

Closed
MylesBorins opened this issue Mar 24, 2021 · 5 comments
Closed

[RRFC] Add type to npm init #347

MylesBorins opened this issue Mar 24, 2021 · 5 comments

Comments

@MylesBorins
Copy link

Motivation ("The Why")

The type field is used by many folks to be explicit about the how Node.js interprets the .js extension. It would be great if we could set this field by default, likely to commonjs and give folks the ability to overwrite the default with module (or any other future module type)

Example

{
  "type": commonjs"
}

How

Current Behaviour

Currently this is the default output of npm init --yes

{
  "name": "$FOLDERNAME",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "$USERNAME <$EMAIL>",
  "license": "ISC"
}

Desired Behaviour

{
  "name": "$FOLDERNAME",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "$USERNAME <$EMAIL>",
  "license": "ISC",
  "type": "commonjs"
}

References

https://nodejs.org/dist/latest-v14.x/docs/api/packages.html#packages_type

@darcyclarke darcyclarke added the Agenda will be discussed at the Open RFC call label Mar 24, 2021
@thescientist13
Copy link

thescientist13 commented Mar 24, 2021

Just wanted to share there has been some initial discussion happening here if that is worth carrying over to this RFC - #75

@ljharb
Copy link
Contributor

ljharb commented Mar 24, 2021

I’m not convinced this is actually helpful. In practice, tutorials have blindly recommended using type:module, and users who follow this advice invariably run into hours of debugging confusion until they realize either to remove it, or, until they learn all the caveats involved.

This is worsened because most ecosystem tooling is not yet able to handle type:module fully. There hopefully will be a time in the medium term where this is addressed, and perhaps the confusion factor would be addressed by that as well, but at the moment my experience helping newcomers tells me that the best thing for now is to avoid type:module (unless one is an expert).

Adding type:commonjs seems like it’d be fine, but if that includes a prompt, then it will be very difficult to concisely convey all the caveats and nuances of the choice, and users are highly likely to find themselves in the same boat i mentioned above.

@darcyclarke
Copy link
Contributor

Just following up here, the general consensus seems to be to leave the base template of npm init alone & allow for the ecosystem to define templates/standards beyond those defaults (ex. create-pkg/npm init pkg is going to be a standard/default template that's defined by the Node Package Maintenance WG alongside some other tooling - ref. pkgjs/create-pkg#9)

Here's some references to our last few meeting notes:

Going to close based on the above

@jeffschwartz
Copy link

jeffschwartz commented Aug 13, 2022

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

@wesbos
Copy link
Contributor

wesbos commented Mar 10, 2023

I understand not wanting to change defaults, but could we at least get the ability to set init-type=module in our .npmrc file like we do with version, user, email and license? Seems there is no way to set the default to esm.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants