Inconsistent handling of dependent version bumps and changelogs

[ecraig12345]

Currently, when bumping dependencies in packages that didn't themselves change, there's some inconsistent behavior regarding bumpDeps, scope, and ranges like workspace:/catalog:/file:/*.

Normal case (works)

Behavior is reasonable with the default bumpDeps: true, no scope, and internal dependencies specified with semver ranges (like ^1.2.3):

• package version is bumped by dependentChangeType
• package.json dependency ranges are updated
• changelog has entry for dependent-bumped version with "Update some-dependency to x.y.z"

In other cases, various things get weird...

Issues with bumpDeps and scope

bumpDeps: false has some odd behavior today. scope shares some similar issues for out-of-scope packages.

• In setDependentVersions:
  • It still updates package.json dependency versions in dependent packages which don't have changed files and/or are out of scope (whether this should happen is discussed below)
  • It includes those dependent packages in dependentChangedBy, which means writeChangelog creates at least a CHANGELOG.json entry for them with undefined change type.
    • This is also the cause of Incorrect bump notes added when --scope is used #1033
• In bumpInMemory, those extra dependents are added to modifiedPackages.
• modifiedPackages including the questionable dependents is used by:
  • performBump -> updatePackageJsons (during bump or publish) to update package.json on disk
  • publishToRegistry -> getPackagesToPublish to determine which packages to consider publishing
    • with scope, out-of-scope packages would be skipped at this point
    • with bumpDeps: false, could add code to skip them if no calculatedChangeTypes entry (this would be a better way to ensure publishing doesn't fail via validatePackageVersions if a dependent package wasn't bumped and the version already exists in the registry--Skip publishing packages that aren't bumped #1126 improved the behavior but it's not a full fix)
  • publish -> getNewPackages to determine which packages aren't already being published and might not exist in the registry
  • publish -> bumpAndPush -> tagPackages to create git tag for package version (problem: could try to create a tag that already exists since the version wasn't bumped)

Design/conceptual issues

There are also some significant conceptual issues with bumpDeps: false (some of which extend to scope) as originally outlined in #620 (comment)...

Say you have these packages and use bumpDeps: false:

{ name: 'foo', version: '1.0.0', dependencies: { bar: '^1.0.0' } }
{ name: 'bar', version: '1.0.0' }

• If bar bumps to 1.0.1 and bumpDeps is false, that's fine because the range is still satisfied (though syncpack/similar might complain). 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.

Potential better behavior:

• If the new version doesn't satisfy an existing range, updateRelatedChangeType's dependents logic should bump it anyway.
• In setDependentVersion, for packages which weren't previously in modifiedPackages, it should only modify dependency ranges if the new version doesn't satisfy the current range.
  • potential issue: even if the new version is in range, if the dep range isn't updated but the package is published later, the different ranges might cause package managers to introduce unnecessary duplicates
    • maybe add some logic to update only the package.json but ignore for npm-publish/git-tag?
  • potential issue: could get out of sync with linters such as syncpack

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.

Issues with workspace:/catalog: ranges

Assuming bumpDeps: true, dependent bumps for workspace:/catalog: dependencies will mostly work as expected. The exception is that dependent bump changelog entries will be missing (#981) since the version isn't modified by setDependentVersions, and currently in such cases it skips adding to dependentChangedBy.

With bumpDeps: false or scope, the dependent packages won't be considered at all since they don't end up in dependentChangedBy.