I tried searching about this, but it's a tough topic to search, or there isn't anything. Sorry if I'm duplicating.
When working with other developers, we tend to name our npm package versions according to our ticket #. so might look like 1.1.1-ABC123.0.
We are following semmantic versioning, FYI, the last (4th digit) is just to help keep track of which build iteration we are testing.
The question of concern is when you tack on the caret (^) to the version: ^1.1.1-ABC123.0 it resolves to 1.1.1 instead. Why is this? I just want to understand this reasoning. I would think that the 1.1.1-tag.0 would be viewed as a more recent version by node.
Or is this related to development versions versus release versions? (I'm making a guess here) Perhaps node views a stable release version as the most up to date, and ignores any development build you are doing.
npm follows Semantic Versioning, which has a clearly defined, publicly-available specification document.
In your particular case, you seem to be inadvertently (ab)using SemVer’s support for (what the spec refers to as) “pre-release version[s]”, defined specifically in point #9 of the linked spec document.
I would think that the 1.1.1-tag.0 would be viewed as a more recent version by node.
This seems to be where you’re going astray; from the spec, point #9:
Pre-release versions have a lower precedence than the associated normal version.
In short, the way your team is using versioning doesn’t conform to the way SemVer is defined, and so long as you continue to version your packages in this way, you will encounter unexpected behaviors like the one you’re observing.