0

We've setup a recommended setting which contains a npm_hosted for private packages, a npm_proxy for public ones, and a npm_group to group the two, just as the setting shown in https://blog.sonatype.com/using-nexus-3-as-your-repository-part-2-npm-packages.

It works fine until we come with this:

Suppose there's a package a in public npmjs.com, and a package of the same name in our private repo, which, however, has nothing to do with the public one, now I do npm i a, what I expect is installing the private a package, however what is actually installed is the public one.

I tried again with npm i a@1.0.0, and this time the private one is installed.

I checked the public a package, and found that it has no version 1.0.0. So I think nexus is resolving a package like, resolving the semver range against all versions across both packages from the 2 repos.

It is a trouble for me, because I don't want to rename my package just because there's a package of the same name out there which I don't care about at all.

How do I make it resolve to the private a package as long as there's an a package in my private repo?

Jack Lu
  • 139
  • 2
  • 12
  • Have you considered [scoping](https://docs.npmjs.com/misc/scope) your packages ? – Zeitounator May 05 '19 at 21:18
  • Not yet, because I didn't think of nexus making me worry about this, since a private registry is supposed to be separated, in terms of version resolution, from the npm primary registry, but if nexus can't do this, I'll consider scoping. – Jack Lu May 06 '19 at 02:48
  • *Disclaimer: I'm not a Sonatype staff nor supported by them.* I don't think you can blame Nexus here. In my point of view, as soon as you consider publishing your packages, even in a strictly private manner, you are responsible to make sure that your name does not conflict with an existing one. If you use an existing name, it should be the same package and you should only publish privately locally built beta/patched versions. Scoping for npm precisely exists to resolve name conflicts. But my remark is not limited to npm, same goes for yum, maven, pip... – Zeitounator May 06 '19 at 06:27
  • I got your point. I asked this question because I thought the most common case of using this kind of structure is hosting private own packages rather than packages that serve as patches to public packages, so it makes more sense to let the private registry have a separate namespace. I'm not sure how people are using this, so I may be wrong. – Jack Lu May 08 '19 at 03:35
  • Is hosted first in your group order? – joedragons May 22 '19 at 21:21
  • Yes. `npm_hosted` is before `npm_proxy`. – Jack Lu Jun 02 '19 at 05:33

0 Answers0