Conditionally bump dependents on publish

[okjodom]

Bumping dependents in our monorepo causes a lot of churn for package versions. However, turning off bumpDeps is not desirable since we'd still like to keep automated synchrony of versions with bump. Presently, keeping bumpDeps is only important for us on major bumps.

Could we have a scheme for conditionally allowing bumping dependents?

Below is a proposal to improve bumpDeps configuration schema:

1. Current Schema
   bumpDeps: boolean = true by default

2. Proposed Schema

     bumpDeps: boolean | {
         bumpFor?: ChangeType
     }
   

Application:

1. bumpDeps: boolean - maintains current behavior
2. bumpDeps: {} - same behavior as bumpDeps: true
3. bumpDeps: { bumpFor: 'major' } - for any major change, dependents get bumped.
   • Recursion of bumping dependents stops based on the same bumpDeps rule, so only 1 depth of dependents get bumped as patch
4. Similar outcome for bumpFor: 'minor' ... bumpFor: 'prerelease'
5. bumpDeps: { bumpFor: 'none' } - same behavior as bumpDeps: false

[okjodom]

cc @kenotron, @ecraig12345, @JasonGore. Could you help review issue when possible

[ecraig12345]

Very late to this, sorry, but you bring up a good point--I was just looking into a related issue, and I think the current behavior of bumpDeps is fundamentally flawed. (There's a similar potential issue with scope.)

Say foo has a dependency "bar": "^1.0.0":

• If bar bumps to 1.0.1 and bumpDeps is false, that's fine because the range is still satisfied. Same with minor changes for that range.
• But if bar bumps to 2.0.0 or a prerelease version, the range is no longer satisfied. So foo must be bumped to avoid potential duplication within the dependency tree.

I think the scenario you described could be adequately handled without any extra options, if the behavior with bumpDeps: false is updated:

• If the new version doesn't satisfy an existing range, updateRelatedChangeType dependents logic should bump it anyway.
• To ensure consistent ranges within the tree (to prevent package managers from introducing duplicates), setDependentVersions should only modify dependency ranges if the new version doesn't satisfy the current range.
• Have to think about how this interacts with workspace: ranges
• Also consider linters such as syncpack if dep version gets out of sync

This is a breaking change, so I'll add it to the list to consider for the next major beachball version.

(It's less clear what should happen with scope in a similar case where the dep is bumped to a version incompatible with the current range. That issue applies regardless of bumpDeps.)

Edit: it might also make sense to add a separate option like bumpDevDeps?: boolean to disable bumping dependents for devDependencies.