dependency upgrade may bump major versions of transitive dependencies

[iliapolo]

Problem

The dependency upgrade workflow creates the following yarn command to bump the versions in the lock file:

yarn upgrade <list of packages>

According to yarn docs:

The package.json file will be updated to reflect the latest version range. By default, the existing range specifier in package.json will be reused if it is one of: ^, ~, <=, >, or an exact version. Otherwise, it will be changed to a caret (^). One of the flags --caret, --tilde or --exact can be used to explicitly specify a range.

This means that if a dependency uses, for example, * to declare its own dependencies, running yarn upgrade may cause a major version bump.

Example

• cdk8s-cli declares a dev dependency on @types/glob.
• @types/glob declares a runtime dependency on @types/minimatch with *

This results in a dependency upgrade PR that bumps the major version of @types/minimatch:

The build is then failing with:

error TS2688: Cannot find type definition file for 'minimatch'.
  The file is in the program because:
    Entry point for implicit type library 'minimatch'

I'm not entirely sure why exactly it fails, but I know I don't want to deal with major version migrations unless I decide to, even for transitive dependencies.

Possible Solution

When npm-check-updates is executed with --target=minor, we can (optionally) add a --caret to the yarn upgrade command.

Note

Ideally we should just be following whatever version ranges our dependencies declare, because they know best. However, I really don't see a good reason to declare a runtime dependency with * or > - so I would like to have some control over situations like these.

Limiting to only upgrade minor versions seems like a safe bet.

[mrgrain]

Always happy to expose additional options in the API. Not convinced this would be a sensible default though, I don't really want projen to be too much in the business of deciding what upgrades should look like. The standard is to trust the dependencies.