Named snapshot versions have semver sorting conflicts

[mihkeleidast]

Affected Packages

• "@changesets/cli": "^2.22.0"

Problem

I've recently published multiple snapshot versions with different names, and tried to update from one to the other. My package manager (yarn classic) failed to install the newer transitive snapshot version, because the previous one's name was considered newer. This is probably because the named versions are ordered alphabetically.

From this example, you can see that even though the snapshot with name "semantic-colors" has the latest timestamp, it is ordered to be lower than the older "theme-provider" snapshot.
https://semvercompare.azurewebsites.net/?version=0.0.0-semantic-colors-20220527130647&version=0.0.0-theme-provider-20220526071429

Proposed solution

Reverse the order of the timestamp and snapshot name in the version. The following example has the timestamp and name switched and the versions are ordered correctly:
https://semvercompare.azurewebsites.net/?version=0.0.0-20220527130647-semantic-colors&version=0.0.0-20220526071429-theme-provider

[Andarist]

I would probably accept a PR implementing this as an option.

[mihkeleidast]

Why shouldn't this be the default? Isn't it bad that the snapshot versions can conflict (forcing users to think about why something is not installing correctly), while keeping the timestamp first would essentially eliminate this problem?

[Andarist]

Mostly to avoid changing the default scheme within a minor release of Changesets. The current behavior was already out for a considerable amount of time and some people might rely on it.

That being said - when using snapshot versions all dependency ranges etc should be updated to fixed versions to eliminate the transitive dependency issues. If I understand your problem correctly then you might end up with the very same problem with the proposed change, just for a slightly different reason. After all the dates in the generated snapshot versions are also compared alphabetically.

[mihkeleidast]

Thanks, it makes more sense now.

That being said - when using snapshot versions all dependency ranges etc should be updated to fixed versions to eliminate the transitive dependency issues.

This seems like the more correct solution. Is there a way to make snapshot versioning do this, or is it the real issue that should be fixed?

[Andarist]

This seems like the more correct solution. Is there a way to make snapshot versioning do this, or is it the real issue that should be fixed?

I would probably accept a PR implementing this as a default for snapshot releases 😉

[ivanbanov]

@Andarist #859
:)

[ivanbanov]

hey @Andarist about

If I understand your problem correctly then you might end up with the very same problem with the proposed change, just for a slightly different reason. After all the dates in the generated snapshot versions are also compared alphabetically.

You are right, even though it may still make sense to swap the order.
My team uses a script that wraps the changesets cli and controls the user inputs beforehand, in this case the change would save our skin since the tags are managed by the script.

I get your point about the fixed version, but since the change in order is (probably) not harmful, would it still be an option?

[mihkeleidast]

This seems to be fixed by now, versions are without caret and some sort of templating is also possible, I believe.