Skip to content

dependency range bumps are ignored #184

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
jbolda opened this issue Apr 8, 2021 · 2 comments
Open

dependency range bumps are ignored #184

jbolda opened this issue Apr 8, 2021 · 2 comments
Labels
bug Something isn't working

Comments

@jbolda
Copy link
Owner

jbolda commented Apr 8, 2021

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.

let version = semver.inc(
  pkg.pkg.dependencies[dep],
  bumpType
);
if (version) pkg.pkg.dependencies[dep] = version;

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.

@jbolda jbolda added the bug Something isn't working label Apr 8, 2021
@cowboyd
Copy link
Collaborator

cowboyd commented Apr 9, 2021

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.

@nothingismagick
Copy link

I have faced this in rust projects recently too, and I never want anything other than a strict pin within the confines of the monorepo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants