Skip to content

[BUG] credential checks don't resolve environment variable references #8513

Description

@hashtagchris

Is there an existing issue for this?

  • I have searched the existing issues

This issue exists in the latest npm version

  • I am using the latest npm

Current Behavior

Commands like npm whoami and npm publish perform a credential check, and can remind you that you need to be logged in. However if a credential configuration setting references an environment variable (${FOO}), the credential check passes regardless of whether the environment variable is set.

Expected Behavior

The credential check first resolves any references to environment variables. If an environment variable is not set, or alternatively the interpolated string is empty, the credential check warning or error message is produced. Optionally "(environment variable FOO is not set)" could be appended to the message.

Steps To Reproduce

  1. Log out of the registry
  2. Run npm whoami or npm publish --dry-run, confirm you get ENEEDAUTH: This command requires you to be logged in
  3. Update .npmrc to include //registry.npmjs.org/:_authToken=${NODE_AUTH_TOKEN}. Do not set any environment variable.
  4. Run npm whoami or npm publish --dry-run

You should continue to get ENEEDAUTH: This command requires you to be logged in, but don't.

You can reproduce this issue locally, or in a GitHub Actions workflow by using actions/setup-node (ref).

Environment

  • npm: 11.5.2
  • Node.js: v24.4.1
  • OS Name: macOS
  • System Model Name: MacBook Air, Space Gray
  • npm config:
; "user" config from /Users/hashtagchris/.npmrc

//registry.npmjs.org/:_authToken = (protected)

; node bin location = /Users/hashtagchris/.nvm/versions/node/v24.4.1/bin/node
; node version = v24.4.1
; npm local prefix = /private/tmp/dry-run-test
; npm version = 11.5.2
; cwd = /private/tmp/dry-run-test
; HOME = /Users/hashtagchris
; Run `npm config ls -l` to show all defaults.
% cat ~/.npmrc 
//registry.npmjs.org/:_authToken=${NODE_AUTH_TOKEN}

Activity

  1. wraithgar commented on Aug 20, 2025

    @wraithgar
    Contributor

    This is partly a side effect of the initial intent which was to not validate the contents of the config, just to make sure it exists. If and when this is addressed it's important that this doesn't extend into some sort of validation of the token itself, just a check that it exists.

    Validating the token itself is a wholly separate problem space that needs more design and discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Bugthing that needs fixingNeeds Triageneeds review for next steps

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions