[RRFC] configs in in package.json

[isaacs]

Suggested in #36

Request for an RFC to put a section in package.json which would function as a project level config, but also apply to scripts run in the course of installing the packages containing this config section.

Bikeshed on the name of the config section. Established patterns from other cli tools (tap, jest, nyc, babel, typescript, etc.) would suggest that we call it npm.

{
  "npm": {
    "script-shell": "/bin/bash"
  }
}

Argument against using "npm" as the key would be that it is a little weird to say "this bit of package.json is for npm", when really the entire file is for npm.

Another tricky bit needing exploration is the impact of having these configuration values effectively set when running scripts in the course of installation and other lifecycle scenarios. Replacing ./.npmrc in the root project is relatively trivial by comparison.

[markcellus]

Yeah having the npm field would be rather odd in this case for the reason you've already stated, so vote no for that. Everything else seems reasonable but not too familiar with every implication unfortunately.

[darcyclarke]

@isaacs was considering proposing support for a .npmrc.json file (similar to babel/eslint). This could allow for more verbose/structured config over the plaintext .npmrc files today. I'd imagine this would eventually become user's default/preferred method to setting config for npm specifically (beyond any existing/future package.json capabilities). Thoughts?

[ljharb]

This seems like it would just replicate the "possible config format/location" explosion that other tools have. My preference is to stick with the status quo here; i'm not a fan of the RFC for the same reason.

[ruyadorno]

I'm def a big +1 👍 for having a npm or npm-cli section in package.json as an alternative for declaring npm cli configs.

I'm being a bit lazy rn (but I might come back to this later) in which I won't go and compile a list of pros - but it seem to me that the following statement should be easy to agree with:

Namespaced configs in package.json is a reasonable pattern that userland has been using for a while and has wide adoption in the nodejs-cli ecosystem.

Argument against using "npm" as the key would be that it is a little weird to say "this bit of package.json is for npm", when really the entire file is for npm.

I disagree with this argument since in my understanding the entire package.json is for whatever package manager people are using (and nodejs itself), while a npm or npm-cli namespace would allow for setting configs specific to the npm cli itself.

[ljharb]

It's a pattern that userland has allowed for awhile - I'm not so convinced it's seen wide adoption outside of boilerplate generators like CRA (where the user doesn't have a choice).