Allow internal dependents to not be automatically bumped

Affected Packages

First time issue submitter here, so I’m not 100% sure, but I think only these packages would be affected:

• apply-release-plan
• assemble-release-plan
• cli
• config
• types

Problem

I’ll construct a contrived example here to illustrate my real-world problem.

I’ve got a monorepo set up with several shared libraries, foo@1.0.0 and bar@1.0.0, to be used in other applications. These libraries may have internal dependencies. So let’s say that foo@1.0.0 has a dependency on bar@^1.0.0. I make a breaking change to bar@1.0.0 and create a major version changeset bumping to bar@2.0.0.

The next time I run yarn changeset version (or the changeset action runs in CI), in addition to bumping bar@2.0.0, foo@1.0.0 is automatically bumped to foo@1.0.1, and its internal dependency is bumped to bar@^2.0.0. As far as I understand, this is intended behavior.

But what if I needed to make some changes to the foo library before it can use bar@2.0.0? Sure, I could make those changes before releasing bar@2.0.0 and publish both releases together, but should the release of bar@2.0.0 be blocked by the dependent foo library? This problem compounds if there are many packages which all depend on bar@1.0.0, such that coordinating the update of each dependent to be compliant with the new version of bar@2.0.0 before even releasing bar@2.0.0 becomes near impossible.

Here’s my .changeset/config.json for reference:

{
  "$schema": "https://unpkg.com/@changesets/config@1.6.0/schema.json",
  "changelog": "@changesets/cli/changelog",
  "commit": false,
  "linked": [],
  "access": "restricted",
  "baseBranch": "main",
  "updateInternalDependencies": "patch",
  "ignore": []
}

Proposed solution

What I am suggesting is a new config option (perhaps "updateInternalDependencies": "never" or something) which would no longer update internal dependencies to a package when a new version of it is published. This means that each package would need to manually update it’s internal dependencies, but it would allow the releases of packages with dependents to be decoupled from the releases of their dependents.

I’ve sorted this out in theory in my TS monorepo. Since yarn workspaces will install the outdated versions of the internal dependencies in the packages’ node_modules, I used path aliases to point to either the internal dependencies location in that package’s node_modules or to that packages src folder or to . This handles the case where we’re using the current version of the internal dependency and the case where we’re using an outdated version.

As long as this is not a default option, this would not be a breaking change, and it would greatly improve the workflow of my monorepo setup. If I were more familiar with the source code and had the bandwidth, I’d take a crack at this myself. If this is a feature request you all would consider, I’d greatly appreciate it! If there’s any other information that would help with addressing this issue, let me know.

Thanks a lot for your work on this project!! ❤️

[Andarist]

It doesn’t prevent me from creating new changesets, but I think this warning should be suppressed when bumpVersionsWithWorkspaceProtocolOnly is true and the dependency is not using the workspace protocol since using an outdated dependency here is allowed. Let me know what you think.

Yes, definitely this should be allowed.

Perhaps the wording could be updated to saw “All workspace dependents…” or something like that.

Feel free to prepare a PR for this change.

When using the changesets action (@master), I am still getting a changelog entry for bumping the internal dependency of foo on bar, even though it didn’t actually happen.

Would be great if you could prepare a repro case or write a failing test in our repo - this would allow me to get to fixing this much quicker.

[mondash]

@Andarist I have just found another unresolved issue (semi-related to the above mentioned issue). When using the changesets action (@master), I am still getting a changelog entry for bumping the internal dependency of foo on bar, even though it didn’t actually happen.

Ex:

<!-- packages/foo/CHANGELOG.md -->

## 2.0.0

### Major Changes

- xxxxxxx: Some more setup

### Patch Changes

- Updated dependencies [xxxxxxx]
  - bar@2.0.0