RFC21: bring back subset of npm_package_* environs #183
Conversation
|
Is this enough? Are there any on this list we shouldn't include? |
| but npm will _not_ override values with a `<pkgname>:<keyname>` config | ||
| value if one exists. | ||
| * `npm_package_engines_*` | ||
| * `npm_package_main` |
There was a problem hiding this comment.
what about npm_package_exports, npm_package_private, etc? or are these just the ones that have known uses?
There was a problem hiding this comment.
These are the ones that have known uses, have been around a long time, and aren't terribly complicated to put in the environment.
The "exports" field is an object, and if you have something like "exports": {".": {"import": "./index.mjs"}}, that'd env-ify into npm_package_exports___import="./index.mjs" (since . is stripped out) which is a bit weird.
In other words, there is a point where it's fair to say, look, if you wanna know what's in package.json, write a JavaScript program and parse it or do require('./package.json'). The line drawn by RFC21 as it currently stands is "anything"; if you want package.json at all, you parse it, here's the filename, have fun. The pushback (which I think is reasonable) is that there are a few things you might want to put in command lines in the package.json itself, without having to write a whole other script to do it.
So this is just the stuff that's likely to be used by a package lifecycle script, where you might want to have something like "scripts": {"start":"node $npm_package_bin_start_server"} or something.
This implements the change described in npm/rfcs#183
|
Landed and published in 7.0.0-beta.4. (Edit: oops, this is the RFC PR, not the npm/cli PR, sorry. Didn't mean to close.) |
Discussion: https://twitter.com/JessTelford/status/1258549958728286208
CC: @jesstelford