You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG] dangerous check if semver is a valid semver in constructor #354
in the semver class constructor, you are checking if the value is an instance of SemVer
This check is dangerous since many times a package manager can create a tree of packages where you have 2 instances of SemVer in different places in the filesystem.
This leads to a bug where you pass a semver from one package to another then call the constructor and get an error about Invalid Version
How
Current Behavior
An error when you pass a SemVer instance between packages and call the SemVer constructor.
Steps to Reproduce
create 2 packages with different locked semver package version (for example 7.3.1 and 7.3.2)
(This sometimes happen also when the versions are the same, but it's easier to reproduce with different versions)
pass a SemVer instance from one of them to the other and call the SemVer constructor with this version.
Expected Behavior
Test if the value is valid SemVer by it's content (or content + constructor name) instead of using instanceof
References
This happens to me when using yarn berry API even though the core and the npm-plugin uses the same versions of semver.
When installing my tool as global with npm it creates 2 instances of the SemVer because it hoisted another version from another package.
Old issue but imho, getting an error is essential here.
The implementation in another release might (probably will) have different behaviour. It would be a big assumption that you can pass an instance of one semver release to another and expect consistent results (there are no tests for such cross-release cases either).
You could stringify the version first and then create the instance in the other package.
Activity
GiladShoham commentedon Dec 9, 2020
A concrete use case with a reproduce repo is described here
yarnpkg/berry#2224
the reproduce repo is here - https://github.com/GiladShoham/yarn-invalid-version-bug
mbtools commentedon Feb 1, 2024
Old issue but imho, getting an error is essential here.
The implementation in another release might (probably will) have different behaviour. It would be a big assumption that you can pass an instance of one semver release to another and expect consistent results (there are no tests for such cross-release cases either).
You could stringify the version first and then create the instance in the other package.