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
Packages within a monorepo that have a dependency (or devDep in npm) will be bumped when the related package is bumped. Unfortunately, this broken if the dep/devDep is specified as a range. The following snippet out of @covector/apply shows how the version is bumped.
However, semver.inc() can only bump "clean" version numbers and the version variable here returns null.
Note: until this bug is resolved, we recommend pinning all internal / monorepo dependencies if you expect covector to apply the bump for you.
Also note: yarn ignores the version number and happily symlinks these in a workspace. npm does not and will fall back to pulling from the registry. This might mean that, some publishes work fine if the package still falls within the dependency range that you specified. However, since it will, currently, never be incremented, a package may eventually be bumped outside of that range and begin failing. (This is even more nuanced when your versions are < 1 as the commonly used ^ works differently for version numbers < 1.
The text was updated successfully, but these errors were encountered:
Part of me wonders: do you ever want anything than a pin for an intra-repo dependency? Since the updating of dependencies is all built and tested together, what is the harm if @same/a always points to a specific version of @same/b?
It almost feels like even if we fixed this bug, it would be even better to have a --strict mode raised an error if you had anything other than a point release for internal dependencies.
Packages within a monorepo that have a dependency (or devDep in npm) will be bumped when the related package is bumped. Unfortunately, this broken if the dep/devDep is specified as a range. The following snippet out of
@covector/apply
shows how the version is bumped.However,
semver.inc()
can only bump "clean" version numbers and theversion
variable here returns null.Note: until this bug is resolved, we recommend pinning all internal / monorepo dependencies if you expect covector to apply the bump for you.
Also note:
yarn
ignores the version number and happily symlinks these in a workspace.npm
does not and will fall back to pulling from the registry. This might mean that, some publishes work fine if the package still falls within the dependency range that you specified. However, since it will, currently, never be incremented, a package may eventually be bumped outside of that range and begin failing. (This is even more nuanced when your versions are< 1
as the commonly used^
works differently for version numbers< 1
.The text was updated successfully, but these errors were encountered: