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
- SemVer treats pre-releases in the following manner
1.0.0-SNAPSHOT < 1.0.0-SNAPSHOT.1 < 1.0.0-SNAPSHOT.2 < 1.0.0-SNAPSHOT.3… - NPM will always retrieve the latest pre-release version
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.