Can't install private npm module from remote system

[paulcullin]

I just signed up for npm Private Modules, created and published a new private module and can install it just fine on my local machine. I have to run npm login to authenticate with my private credentials before being able to install my private module. This is no problem on my local machine, but when I try to do this in a remote scripted environment such as a CI system, I'm not able to authenticate because npm login is an interactive command. That results in the private module not being found during npm install on the remote system.

Is there a way around this? I'm totally new to private modules and multiple user accounts for npm...

[smikes]

Yes, there is a way around this, but it depends on your CI system. Are you using Travis, or Jenkins, or...?

The short version is, you can copy your login credentials from your .npmrc (which is where npm stores them) and put them on your CI in environment variables that npm will read. If you are using Travis or a similar publicly-visible CI system, then you will need to encrypt these variables -- see http://docs.travis-ci.com/user/encryption-keys/ for an overview of how to do this.

Please let me know if this makes sense, or if my answer fails to address your question.

Thanks!

[localjo]

To build off of this question;

We're setting up a .npmrc in our projects like this;

//registry.npmjs.org/:_authToken=${NPM_AUTH_TOKEN}

And then setting the environmental variable in our CI system. It works great for deployment, but in local development it requires our developers to manually copy the auth token out of their user .npmrc and set an environmental variable on their local system. Not a big deal, but a bit of a hassle for some of our developers.

Is there a workaround for this? Maybe a way that if the environmental variable isn't set, npm gets the key from the user's .npmrc instead of the project's?

[localjo]

The workaround I came up with is to run
npm config set //registry.npmjs.org/:_authToken $NPM_AUTH_TOKEN
before npm install in our CI system. It seems to work, though I'm not 100% sure if that approach is advisable.

[localjo]

Cordova? ;)

[smikes]

Whoops, wrong issue. ;-)

[MarkHerhold]

+1 for clarification on how this is "supposed" to work

[orlade]

I think @josiahsprague's workaround should instead be npm config set //registry.npmjs.org/:_authToken=$NPM_AUTH_TOKEN (= instead of space after _authToken).

[othiym23]

both ways should work!

[orlade]

Hmm, okay. I was having problems, but I think they were deeper than that. Trying to run npm install of a private NPM package on Codeship was failing and giving different errors depending on whether I used an equals or space. In the end neither worked and I had to login as a different user, which is odd but a different issue.

[vjpr]

To summarize:-

Note the ordering of the below commands for each option:-

Option A

1. Ensure NPM_TOKEN is set.
2. npm config set //registry.npmjs.org/:_authToken=$NPM_TOKEN
3. npm install / npm run build / npm start

Option B

1. echo "//registry.npmjs.org/:_authToken=\${NPM_TOKEN}" > ~/.npmrc
2. Ensure NPM_TOKEN is set before running an npm command.
3. npm install / npm run build / npm start

---

When using Docker, the ordering is important for caching. Setting ENV NPM_TOKEN=xxx should not invalidate the caching when its called. You may be just be updating it because it became invalid somehow. If it did invalidate the cache this would cause a lengthy node_modules reinstall. (I need to double-check how Docker's ENV works with caching.)

There are also a bunch of other environments you might be deploying to which would need consideration before deciding on the best approach:

• CI (e.g. Codeship, CircleCI)
• PaaS (e.g. Heroku, Elasticbeanstalk)
• Local native development machine
• Vagrant
  • Shell provisioner
  • Base box
• Virtual machine (via Packer, etc.)
• Ansible, Chef, Puppet
• Docker
  • Local
  • Production

As an environment variable that is passed in during each build seems the best. The question is just how much does this impact developer productivity and deploy times.

[snopeks]

Hello @pcullin-ratio, we haven’t heard back and we’re trying to clean up some issues. If this is still a problem, can you please reply and let us know? We’ll be happy to reopen if necessary.

[StephanBijzitter]

@snopeks I do still have an issue that is likely the same.
See linked issue below.

[tomccabe]

Struggling with this as well; We have our credentials in an encrypted file on CI and use a bash script to login with the prompts, which is annoying and sloppy. So is using a token that wasn't generated on the box and can't be automatically updated if it expires/whatever.

Why not check for credentials in .npmrc? I can probably guess the answer to that, but support for automated login for CI should've gone hand in hand with private registries.

[ashmind]

In the solutions above, doesn't npm config set save the token in user's .npmrc?
If so, it feels like a potential problem if the build server has a shared user.