ERROR Failed to replace env in config: ${NPM_GITHUB_TOKEN}

[isla-nye]

pnpm version: 7.6.0

All pnpm tasks fail when NPM_GITHUB_TOKEN is missing in .npmrc.

We use a GitHub token to authenticate with GitHub packages. Previously, we made sure this was available as an environment variable when we ran pnpm install. However, we did not make it available in subsequent steps which do not require authentication, for example to run scripts.

.npmrc:

@xxxxx:registry=https://npm.pkg.github.com/
//npm.pkg.github.com/:_authToken=${NPM_GITHUB_TOKEN}

This has been working with pnpm versions previous to 7.6.0, but has started failing with error:

ERROR  Failed to replace env in config: ${NPM_GITHUB_TOKEN}

We've therefore pinned pnpm to 7.5.2 for now.

Expected behavior:

NPM_GITHUB_TOKEN variable is only used when authentication is needed

Actual behavior:

All pnpm commands fail with

ERROR  Failed to replace env in config: ${NPM_GITHUB_TOKEN}

Additional information:

• Windows, macOS, or Linux?: Linux

This could be intended behaviour as of version 7.6.0, but it is tricky for multi-step Docker builds where one of the steps is to install dependencies. We do not make NPM_GITHUB_TOKEN available to subsequent steps, so would have to remove .npmrc instead from subsequent steps (which would be our approach if it were intended behaviour). It would also be helpful if this behaviour is documented, particularly if it's due to a version upgrade.

[shubham-bibliu]

Do we have any updates on this?

[zkochan]

This was caused by pnpm/npm-conf#6

cc @JonathanUsername

Related #5065

[JonathanUsername]

Hi, as mentioned in that PR, I said I think this is likely a breaking change. I'm sorry you got hit with this!

The previous behaviour, as explained in that PR, is to swallow errors in variable expansion, so in our case we had a missing variable and no idea which one or where. In a monorepo project, which is by design predominantly to manage large and cumbersome codebases, this means a long hunt for the bug. We had no idea this was the issue, and the only thing that led us to it was the failure of some packages to be hoisted.

The new behaviour that I added was simply to error if any of the files got a non ENOENT error in reading. This is similar to what is done elsewhere in the same source file.

I would suggest then one of two options:

• Either reduce the error to a stderr warning
• Or document the new behaviour

Ideally I would have put this as a major version change, since it's clearly breaking existing behaviour. I would however be careful not to simply revert as swallowing errors without any report caused a painful bug hunt for us, and I can't imagine when that is the expected behaviour.

[sammarks]

I believe a stderr warning would be the best solution, as you don't always want to fail whenever variable resolution inside npmrc fails (in the case of simply running scripts, for example).

That way we solve both worlds. No more painful hunt for which file isn't resolving properly, and no need to specify environment variables the npmrc requires every time you need to run a script.

Additionally, it's a bit of a security risk to specify those environment variables in more places than you actually need them, since in my case the variable inside my npmrc is my GitHub token. That way we lessen the risk of some script accidentally exposing important security tokens.