Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

'npm publish' uses user data from ~/.npmrc instead of the project specific .npmrc #5717

Closed
necccc opened this Issue · 17 comments

6 participants

@necccc

Scenario:

  • I want to use an npm module with my private npm registry (in this case: sinopia)
  • In the project .npmrc I set the registry to my private one
  • I set a username in sinopia with publish access, this user is not registered in npm
  • I set the same user in the project .npmrc
  • doing npm publish in the project folder results a 403 error message from the private repo

After doing some debug it seems, 'npm publish' only recognizes the registry from the .npmrc file, but not the username, and it tries to publish with my user from ~/.npmrc

The only workaround I've found, is to create npm the user I've set in the private registry,
'npm login' with it, then try to publish - it succeeds, but i've to re-login every time I've want to update that module in the private repo.

@timoxley
Collaborator

you can specify a registry in the package.json: https://www.npmjs.org/doc/package.json.html#publishConfig

@rlidwka

currently there is no such thing as a per-project npmrc

are you sure?

@rlidwka

PS: it's not really a bug though. It's called "project-specific npmrc" for a reason, you shouldn't keep any user-specific data there.

If you're looking for the ability to publish packages to public and private registry without logging in and relogging in, there are better ways to do it. I know at least two of them: registry-specific configs and scoped packages.

@timoxley
Collaborator

oh heh I missed that.

@tjwebb

currently there is no such thing as a per-project npmrc

are you sure?

You are using 1.5.0-alpha3, then?

@timoxley
Collaborator

@tjwebb glad I wasn't the only one who missed it, but it looks like per-project npmrc has been there since at least 1.4.13, check all the tags this commit lives in:

image

@tjwebb

whoa. obscurity doesn't suit this feature. I must have not read all the documentation I thought I had

@necccc

Thanks @rlidwka , any good practical guides for registry-specific configs and scoped packages?

@rlidwka

@necccc ,

First of all, add publishConfig: {registry: "http://private-registry-address/"} to your package.json's in all your private packages. This is a necessary feature to make sure that those packages will never be published to a public registry by mistake.

1. Scoped packages.

This is a great idea that's going to be in npm 1.5, but it is not widely supported. You can look details in #5239, but unfortunately even npm registry doesn't support it yet.

You name your package like this: @username/package, and configure npm so all requests to "@username" would be forwarded to your private registry.

And the obvious restriction is that you have to name your packages in a particular way.

It's unusable right now, but it'll be very useful in the future.

2. Registry-specific configs.

This can be used right now, but vanilla npm <=1.4 can't do that, so you have to use its fork - yapm. The feature is described here.

Basically, you do these things:

$ yapm login --registry https://registry.npmjs.org/
... enter your public credentials...
$ yapm login --registry http://localhost:4873/
... enter your private credentials...

After that your ~/.npmrc would look like this:

[registries."https://registry.npmjs.org/"]
_auth = dXNlcjpwYXNzd29yZA==
email = public@example.org

[registries."http://localhost:4873/"]
_auth = dXNlcjI6cGFzc3dvcmQy
email = private@example.org

So you could use those registries at the same time without re-logging. If you want to publish something, just run yapm publish in a particular folder, it'll pick up registry from publishConfig automatically.

@necccc

Thx a lot, scoped packages indeed look great, until then...

I've managed to do this without yapm - putting the _auth and other information to my project-specific .npmrc, and there it was, working npm publish to sinopia if i run it from that dir, and using my global credentials and registry everywhere else (it was pretty easy after findig out that _auth is just a base64 encoded string from the ':' concatenated credentials - so my way will definitely break if npm changes the 'encryption' of that :/ )

@othiym23
Owner

Heya, @necccc,

I wouldn't worry too much about the encoding (it really doesn't deserve to be called encryption) changing out from under you. @isaacs just added a useful shim that will preserve the behavior of _auth fields for the default registry even in the new, multi-registry version of npm.

Eventually npm's auth will change much more dramatically, but that will be the transition to bearer-based auth, and everybody will get lots of warning before that happens. Having per-project registries / credentials should work well until then.

@othiym23
Owner

This is a great idea that's going to be in npm 1.5, but it is not widely supported.

The support for this in the npm 1.5 CLI is there for npmE (I don't feel like typing "npm Enterprise" every time I talk about it, so I'm just using the abbreviation everywhere, starting now), and it will be supported by the primary registry before the end of the year, as part of our support for private modules.

This can be used right now, but vanilla npm can't do that, so you have to use its fork - yapm.

This is no longer true – the npm 1.5 alphas all have support for being logged into multiple registries simultaneously. npm login --registry=https://registry.npmjs.org and npm login --registry=http://npme.company.com:8080/ results in this $HOME/.npmrc:

//registry.npmjs.org/:_password=deadbeeffeedbead
//registry.npmjs.org/:username=othiym23
//registry.npmjs.org/:email=ogd@aoaioxxysz.net
//npme.company.com:8080/:_authToken=feedfccfbead4e4d5a11016e80807d0b

You still need to either set the registry in publishConfig or pass it on the command line, but the credentials will be loaded from $HOME/.npmrc and applied as needed.

@rlidwka

putting the _auth and other information to my project-specific .npmrc

I hope this .npmrc is defined in your .gitignore/.npmignore? 'cause publishing your own credentials looks like a bad idea.

This is no longer true – the npm 1.5 alphas all have support for being logged into multiple registries simultaneously.

Thanks, what I meant to say was "npm 1.3.x-1.4.x". npm 1.5 can do that, but they support scoped packages which is a superior solution.

I wonder, does it support all config keys, or just username/password/email/authToken? Can I add:

//registry.npmjs.org/:prefix=/home/user/npm/public
//private.registry:8080/:prefix=/home/user/npm/private

... to separate public and private modules for example?

@necccc

I hope this .npmrc is defined in your .gitignore/.npmignore? 'cause publishing your own credentials
looks like a bad idea.

I know, but all these are goinng in a private registry, unaccessible from outside than our cluster, so currently I don't really worry about that. But it's still a valid issue, so after 1.5 we move this to scoped packages, and multi-registries.

@othiym23 othiym23 added the support label
@hurrymaplelad hurrymaplelad referenced this issue in goodeggs/generator-goodeggs-npm
Merged

Level up private package generation #16

@smikes

Can this issue now be closed?

It looks like you were able to find ways to achieve the thing you wanted to do, using existing but poorly-documented features.

We are trying to clean up older npm issues, so if we don't hear back from you within a week, we will close this issue. (Don't worry -- you can always come back again and open a new issue!)

Thanks!

@necccc

Yes, you can close this.
Thank you

@othiym23
Owner

Closing as resolved.

@othiym23 othiym23 closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.