Managing multiple npm registries in .npmrc for different teams

Other Questions NPM
1

I’m working on a project where we need to handle two different npm registry setups for separate teams.

Current Setup for Team A:
We’re running a Nexus OSS instance that acts as our private npm registry. Our configuration includes a combined repository called npm-combined which contains both a proxy to the public npm registry and our private packages.

Our current .npmrc looks like this:

registry=http://our-nexus-server/repository/npm-combined/
always-auth=true
//our-nexus-server:_authToken=abc.def.ghi.jkl

Upcoming Team B Requirements:
Team B will be joining the project soon and they have their own official npm enterprise account with a different authentication token:

//registry.npmjs.org/:_authToken=mno.pqr.stu.vwx

The Challenge:
I need to figure out how to combine these two configurations in a single .npmrc file so both teams can work on the same codebase without conflicts.

I’m considering a few approaches:

  1. Using npm scopes to separate the registries
  2. Removing the proxy setup from our Nexus configuration
  3. Simply combining both auth tokens like this:
registry=http://our-nexus-server/repository/npm-combined/
always-auth=true
//our-nexus-server:_authToken=abc.def.ghi.jkl
//registry.npmjs.org/:_authToken=mno.pqr.stu.vwx

What’s the best approach to handle this multi-registry scenario?

2

Option 3 should do the trick. The tokens don’t clash since they’re for separate registries. Just ensure Nexus can reach npmjs, and u should be all set!

3

Been there! We had the same issue when merging with another team that used different registries. Scoped packages are your friend here - let Team B keep their scope while your Nexus stays as default. No conflicts, everyone keeps control of their stuff. Just add @teamb:registry=https://registry.npmjs.org/ to your .npmrc with their auth token. Default stays on Nexus, but anything with @teamb scope hits their npm enterprise registry automatically. Saved us tons of deployment headaches since everything stays cleanly separated.

4

Had the same issue last year when we acquired another dev team. Keep your Nexus as the default registry and set up Team B’s npm enterprise access through scope-specific config. Here’s the catch everyone misses - your Nexus proxy needs proper auth passthrough for public packages Team B pulls from their enterprise account. We had to tweak our Nexus routing rules because some enterprise-licensed packages weren’t proxying right. If Team B has private scoped packages on their enterprise account, you need the scoped approach. Don’t just combine auth tokens or those packages won’t resolve through your Nexus proxy.