The npm-snapshot is used for snapshots and npm-hosted contains non-snapshot versions.
A specific library version 1.0.5 has been published to npm-hosted. After that, the version 1.0.4-SNAPSHOT has been published to the npm-snapshot. So I assume that both repositories contain now the library with the ‘latest’ tag; the npm-snapshot latest tag resolves to 1.0.4-SNAPSHOT and the npm-hosted latest tag resolves to 1.0.5
Now, if I get the latest library from the npm-group, I would expect to get the version 1.0.4-SNAPSHOT as the npm-snapshot repo is listed as a first member of the npm-group. What I get however is the version 1.0.5.
If I remove the npm-hosted repo from the npm-group’s list so it becomes:
npm-snapshot - hosted
npm-proxy - proxy
then I get the expected version 1.0.4-SNAPSHOT
Is this an expected behavior and why?
(Edit - it is possible that the 1.0.4-SNAPSHOT has been published first, then the 1.0.5 and after that the 1.0.4-SNAPSHOT has been again overwritten)
I don’t think the order of repositories in the npm-group have any impact on the way artifacts are downloaded. So basically from nexus/maven’s point of view 1.0.5 is considered as a stable version of the artifact, meaning before 1.0.5 release there exists a 1.0.5-SNAPSHOT or in your case 1.0.4-SNAPSHOT. So now if you attempt to consume the artifact nexus provides you with the latest stable version of the component. So I’d say this is an expected behavior.
No, 1.0.4-SNAPSHOT is an unstable artifact which receives update, it is a moving target toward the stable release. After the stable release usually artifact versions are incremented.
Note that the order of the repositories listed in the Member section is important. When the repository manage searches for a component in a repository group, it will return the first match. To reorder a repository in this list, click and the drag the repositories and groups in the Members list or use the arrow buttons between the Available and Members list. These arrows can be used to add and remove repositories as well.
Also, when I have published another version, this time 1.1.0-SNAPSHOT to npm-snapshot, the npm-group now returns this version for the ‘latest’ tag. I also wonder if from the Nexus point of view the 1.0.4-SNAPSHOT is any less stable than lets say the version 1.0.4, as the two member repositories, npm-hosted and npm-snapshot are no different from the configuration perspective.
Looking over docs it appears that the repositories order indeed matters. However, my previous comment still stands with regards to the way versioning are treated. So nexus should honor the repository ordering to find the latest artifact. Going back to your original scenario, given the stable release for the major version of 1.0.x exists, it’ll be made available, in this case 1.0.5. In your 2nd scenario you’ve deployed 1.1.0-SNAPSHOT to the snapshot repo, since there’s no stable release exist say 1.1.0, I’d assume 1.1.0-SNAPSHOT is picked up for the latest artifact.
It is indeed less stable, as 1.0.4-SNAPSHOT is the SNAPSHOT of its stable release 1.0.4.
I’m fairly sure what is happening here is that the group metadata is a “merged” view of the metadata and that the 1.0.5 version is considered a later version than 1.0.4 so it’s considered “latest”. Take a look at this stack overflow post to see one way to get around this behavior. Using SNAPSHOT in private NPM like in Maven - Stack Overflow
Thanks @hoomanb and @mmartz. Yes, that may be it - I just didn’t read the SemVer specs carefully, as it says:
A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
This actually makes sense and I would say it is a mistake to expect the SNAPSHOT version if the corresponding "normal’ version exists.