Feature Request: Option to prevent auto bumping peerDependencies

[SevenOutman]

The Problem

Hi team, thanks for making this tool! It's been helpful to keep our packages up-to-date in the monorepo.

One thing that turns out inconvenient is that, beachball does not seem to handle peerDependencies properly, by automatically bumping peerDependencies version when new versions are published.

For example, there is a base package and a feature package in the monorepo, and base is a peerDependencies of feature.

{
  "name": "@org/feature",
  "version": "1.0.0,
  "peerDependencies": {
    "@org/base": "^1.0.0"
  }
}

When publishing a new version of @org/base, say 1.1.0, beachball would update the feature's package.json to depended on the new version of base.

{
  "name": "@org/feature",
- "version": "1.0.0,
+ "version": "1.0.1,
  "peerDependencies": {
-   "@org/base": "^1.0.0"
+   "@org/base": "^1.1.0"
  }
}

This is not expected. Unlike dependencies, bumping peerDependencies version means that feature no longer works with the older version of base, which is both false and breaking.

This Proposal

Can we have an option say --bump-peer-deps for beachball bump and beachball publish that, when set to false, prevents beachball from bumping the peerDependencies versions.

Any thoughts?

[jvince]

@SevenOutman This would make sense because your @org/base as peer dependency accepts minor version changes. Have you tried changing the dependency range from ^1.0.0 to ~1.0.0?

[SevenOutman]

Thanks @jvince for your response! However I don't think this works for me.

Have you tried changing the dependency range from ^1.0.0 to ~1.0.0?

With this, when I publish base 1.0.1, I will still have the peer dependencies bumped, right?

My point was that peer dependencies should not be auto bumped at all. Because its semantic is significantly different from that of dependencies/devDependencies - for which auto-bumping is fine.

Increasing the version of a peer dependency declaration equals removing the previous versions from the supported version range, which alone is a breaking change (for reference semver/semver#502 (comment)).

Take typescript and a ts-based tooling package for exapmle, only when my packages starts using the new features in ts 5.6 should I increase the peer dependency to 5.6. I'm never supposed to increase it only because a new version is out. Otherwise my user will have to upgrade their ts to 5.6 in order to use my package, while it actually works with earlier ts versions.

[jvince]

@SevenOutman
I am new to the concept of monorepos and also had some misconceptions about beachball.

You are quite right about the peer dependencies, they should not be auto-bumped. Maybe the best approach when you have a case where you have some package in monorepo that has peer dependency to some other package(s) from the same monorepo is to move that peer dependency package to a separate repository(?).

As for the dependencies I assumed that the beachball would skip the bumping of the dependant package if the semver was not in the range. For example, let's assume two packages in the monorepo, package A (1.0.5) and package B (1.0.1). Package B has a dependency on package A defined as ~1.0.0. Now let's assume that package A gets some new functionality and its version gets bumped to 1.1.0. Should you update the dependency to package B in package A? Well according to semver yes because it should not have any breaking changes which in the real world might not happen.

All said, I really like the concept of change files and will start using it in our new project.