search

sonatype / nexus-public

Sonatype Nexus Repository Open-source codebase mirror
https://www.sonatype.com/products/repository-oss-download
Eclipse Public License 1.0
1.96k stars 581 forks source link

npm tags in group repositories not correctly resolved #382

Open leabaertschi opened 7 months ago

leabaertschi commented 7 months ago

We have a Nexus 3 with a group npm repositories. In there are the following repositories:

To npm-releases we only publish packages with tag latest and to npm-snapshots we only publish packages with tag canary. Nevertheless, when accessing the meta data for a package in npm-snapshots, the dist-tags contain the expected canary tag, but also a latest tag with the same version (they are all pre-release versions like 1.3.0-story-4750.3). The metadata in the npm-releases repo correctly only shows a latest tag with the stable version of the latest release. When looking now at the metadata of said package in the group repo it shows the latest and canary tags from npm-snapshots, although npm-releases comes first in the order of repositories.

In my opinion there are two things that don't work as expected:

  1. in npm-snapshots there should be no latest tag
  2. due to the order of repos the latest tag should not have the version from the npm-snapshots repo
nblair commented 7 months ago

Hi @leabaertschi - thanks for opening an issue. I don't quite understand from your message. When you use the term "tag," are you referring to the Pro tagging feature. If so, as a Pro customer someone from your organization can open a ticket with Sonatype Support.

If it's not in relation to that feature, can you provide a few more specific examples of package names/versions, and what the resulting metadata looks like?

leabaertschi commented 7 months ago

Hi @nblair. I'm talking about npm dist tags. I'll try to explain some more.

Let's say we have a package named MyPackage. While working on it I'm creating a pre release with a version 1.3.0-story-4750.1 so I can use and test it in another project. We publish this package to the npm-snapshots repository with an npm dist-tag canary by executing npm publish --tag canary --registry REGISTRY/npm-snapshots from within MyPackage. If I now look at the metadata for MyPackage I get the following dist-tags:

"dist-tags":{"canary":"1.3.0-story-4750.1","latest":"1.3.0-story-4750.1"}

My expectation is that there is only a canary tag, I never tagged this package with the latest tag.

Now I'm done with my changes and release a proper version 1.3.0 of MyPackage and push that one to npm-releases with an npm dist-tag latest. When looking at the metadata in the npm-releases package, I get a latest dist-tag with version 1.3.0, as expected. If I now however look at the metadata for MyPackage in the group repository (consisting of npm-releases and npm-snapshots in that order), I get again:

"dist-tags":{"canary":"1.3.0-story-4750.1","latest":"1.3.0-story-4750.1"}

Since npm-releases comes first in the order of repositories, I expect to get 

"dist-tags":{"canary":"1.3.0-story-4750.1","latest":"1.3.0"}

or

"dist-tags":{"latest":"1.3.0"}

I hope this helps. Let me know if I can provide more information.

zarom commented 1 month ago

Hi! Got exact same issue.

We are publishing pre-release versions into "dev" repository with dist-tag latest_testing and releases into "release" with latest dist-tag. Both repositories accessible through group repository, where release-repo is above dev-repo. When I pull from group repo by latest tag, often I receive packages from dev-repo.

@leabaertschi may be you found some workaround to share?

leabaertschi commented 1 month ago

Unfortunately not

mrprescott commented 1 month ago

@leabaertschi @zarom Unfortunately, the npm registry spec doesn't look like it was designed to handle the case of a component whose versions are split between two registries. Supposedly, every component must have a latest tag defined, which means there must be a latest version in @zarom's dev or snapshots registries, not just the releases registry.

  1. How would you expect this to behave?
  2. Would you want the ability to suppress the automatic latest tag updating in the snapshots/dev registries?
  3. When you push snapshots/pre-release builds, are you always specifying the tag? (Which per the npm-dist docs, is needed to suppress the automatic latest tag creation.)
  4. What benefit are you getting from having multiple repositories, do you have some users that can only see one and not the group/both?
zarom commented 1 month ago

We mostly publishing via Nexus rest-api from CI, perhaps the problem is related to this method of publishing.

@mrprescott

  1. Expecting first repository in group takes precedence when same dist-tags are resolved. Alternatively, last (by timestamp) published package may takes precedence when same dist-tags are resolved.
  2. Suppressing latest tag creation will resolve our issue
  3. Yes, we are always specifying the tag - latest_testing for pre-release and latest after release
  4. All dev-teams instructed to configure only one registry to access all versions of packages in any numbers of nexus-instances. This approach allow easer configuration for dev-teams to access release or pre-release versions if needed, and at same time flexible configuration for infrastructure.
leabaertschi commented 1 month ago
  1. I think what would solve the issue for us is if the the order of repositories was taken in to account. So if a latest tag is found in the first repository, that is the one that is used. By timestamp would only work if there was no latest tag in the snapshot repository
  2. That would solve the issue
  3. Yes, we always publish snapshots with the canary tag
  4. For us it's mainly about clean up, the snapshot repository is cleaned up more often than the release repository