[BUG] npm_package_ variables do not work on npm 7

[robross0606]

Since the upgrade to npm v7, no npm_package_ variables work.

Current Behavior:

Using npm 7, npm scripts cannot access anything other than the following fields:

npm_package_json
npm_package_name
npm_package_version

With npm v6, other variables were exposed. For example, if we had a section like this:

  "dockerConfig": {
    "imageRepo": "some.server.com/org/project/service",
    "releaseImageRepo": "org/project/service"
  }

this is exposed in npm 6 as $npm_package_dockerConfig_imageRepo. This no longer works with v7 at all.

Expected Behavior:

$npm_package_ variables should be exposed as described in documentation.

Steps To Reproduce:

1. Set up custom section in package.json
2. With npm v6, run npm run env. Note existence of custom available variables.
3. Switch to npm:latest (v7) and run npm run env. Note all custom variables are missing.

Environment:

• OS: Windows or Linux
• Node: 14.15.4
• npm: 7.5.2

[robross0606]

Oh, apparently this was covered on the "beta" announcement but not mentioned as far as I can tell on the GA announcement. The link to the actual RFC 21 is also a 404 error. It is also not mentioned at all on the v7 online documentation.

[erezrokah]

@robross0606 looks like npm_package_config* still works

[robross0606]

@robross0606 looks like npm_package_config* still works

As per RFC21, that is not true. I can confirm this with testing by toggling back and forth between v6 and v7 of NPM. This is not a bug, just a glaring omission in the GA announcement if you weren't tracking the beta announcements. Caught us off guard.

I should also point out that the official documentation is still pointing to NPM v6 as "LTS" and stable while NPM v7 is listed as "development" (https://docs.npmjs.com/cli/). This is no longer accurate since the tags for NPM "LTS" have been changed to point to v7.

C:\Code>npm dist-tag npm
latest-1: 1.4.29 
latest-2: 2.15.12
latest-3: 3.10.10
latest-4: 4.6.1  
latest-5: 5.10.0 
latest-6: 6.14.11
latest: 7.5.2    
lts: 7.5.2       
next-2: 2.15.12  
next-3: 3.10.10  
next-4: 4.6.1    
next-5: 5.10.0   
next-6: 6.14.11  
next-7: 7.5.2    
next: 7.5.2   

[markmsmith]

This is also a breaking change for our teams, who have a very similar use case for docker configuration and other dependency config being passed to short shell script commands. Going to a full parsing of the package.json just to get these values is painful.

[pmosconi]

Same for our team: we are using npm run scripts that include variables and among other things deploy to test and production.
Just to make sure: there is no going back and npm_package_variables will not reintroduced?

[darcyclarke]

@robross0606 apologize for the confusion here. We did modify/remove many environment variables (re. https://github.com/npm/rfcs/blob/latest/implemented/0021-reduce-lifecycle-script-environment.md); Also, our docs are slightly stale because of a build failure - this should be resolved by early next week. The latest/greatest CLI docs are in the repo/CLI itself (ex. npm help-search <search>)

[markmsmith]

@darcyclarke Can you confirm that we can work around this change by moving our values under the config key, and that passing values from there will keep working in future releases?

[darcyclarke]

@markmsmith we shouldn't be removing any other env vars from the existing scope of what was documented in that RFC to my knowledge. We've actually only ever agreed to continue supporting more; That said, the entire point is to limit the scope of config we're passing along through/too lifecycle events - if npm_package_config* has the information you need today, it should still have it tomorrow.

[amclin]

This is a significant breaking change not mentioned in the NPM 8 GA breaking changes. Other npm_package_ namespaced variables no longer exist outside of npm_package_config* and npm_package_version. If something depended on npm_package_myuniquekeyfrompackagejson_foobar, it is broken in NPM 7 and 8 even though it worked fine in NPM 4-6.

[darcyclarke]

@amclin it was a documented breaking change in npm v7 with a corresponding RFC where it was thoroughly discussed; this is why there isn't a reference to it in v8's changelog.

[robross0606]

@darcyclarke, please re-post the link to the release changelog where this is covered because your link is dead. I came back to look and it is still not covered anywhere in the published release changelogs for npm 7, 8 or 9. AFAICT, it is still only buried in the RFC and in some pre-release notes.