I have a very simple working setup:
Lib A Lib B
publish 1.0.0-SNAPSHOT -> Private Registry -> npm insta
Idea 1
You can sort of mimic this behavior if you "abuse" the pre-release part of SemVer. I've used the following strategy successfully:
Publish your modules with -SNAPSHOT
but append an incremented number each time you publish (-SNAPSHOT.#
or -SNAPSHOT-#
).
For instance: "x.x.x-SNAPSHOT.1"
the first publish, then "x.x.x-SNAPSHOT.2"
the second publish and so on.
Make sure you use a consistent pattern. So, for instance, if you used dots, stick with dots, or if you used dashes, stick with dashes.
For dependent modules, you only need to declare your version as
"^x.x.x-SNAPSHOT"
and NPM will fetch the latest version.
All of this works due to 2 reasons
1.0.0-SNAPSHOT < 1.0.0-SNAPSHOT.1 < 1.0.0-SNAPSHOT.2 < 1.0.0-SNAPSHOT.3
...Caveat: this will only work for patch versions. Technically 1.2.x-SNAPSHOT is greater than 1.1.x-SNAPSHOT, however, SemVer does not consider this when using pre-releases.
From the docs:
If a version has a prerelease tag (for example, 1.2.3-alpha.3) then it will only be allowed to satisfy comparator sets if at least one comparator with the same [major, minor, patch] tuple also has a prerelease tag.
For example, the range >1.2.3-alpha.3 would be allowed to match the version 1.2.3-alpha.7, but it would not be satisfied by 3.4.5-alpha.9, even though 3.4.5-alpha.9 is technically "greater than" 1.2.3-alpha.3 according to the SemVer sort rules. The version range only accepts prerelease tags on the 1.2.3 version. The version 3.4.5 would satisfy the range, because it does not have a prerelease flag, and 3.4.5 is greater than 1.2.3-alpha.7.
Idea 2 Again, this is another "hack". If you're ok with losing the patch part of SemVer, you can publish your versions as
x.x.<unix epoch ms>
.
The unix epoch is ever increasing (at least until 2038 for 32 bit) and each time you publish, you will always be publishing a greater version.