search

hyperledger-cacti / cacti

Hyperledger Cacti is a new approach to the blockchain interoperability problem
https://wiki.hyperledger.org/display/cactus
Apache License 2.0
344 stars 286 forks source link

ci(github): add dependency version consistency custom-check #3612

Open petermetz opened 2 weeks ago

petermetz commented 2 weeks ago

Problem Statement

In our monorepository code reviewers have to manually keep track of contributors using the correct version string for packages and their dependencies.

Types of issues that arise (not a complete list)

  1. We are on 2.0.0 and people send in a PR with a package with version 0.0.1 or 2.0.0-rc.1 or something else that's outdated.
  2. We are on 2.0.0 and people send in a PR where some of their local package dependencies use outdated versions of other packages. For example the core package declares that it depends on the common@1.0.0 package or for another exmaple, the core-api package declares that it depends on the common@2.0.0-rc.1 package. Both of these cases are wrong becaus they should only be using the current latest relesae version which in this case is 2.0.0
  3. Third party dependencies are being inconsistently dependend on. For examples 5 different packages end up using 5 different versions of express or @grpc-js/grpc which causes compilation issues across the board.
  4. Sometimes people make the effort to be consistent but then versions change on main and they don't realize that their pull request now needs updating just because of this. The issue is that git won't mark this as a merge conflict if it can auto-resolve the merge by using the wrong version so we need tooling to makes this type of mistake impossible to help both code reviewers and contributors alike (less manual effort for everyone)

Acceptance Criteria

  1. Use the software provided at https://github.com/bmish/check-dependency-version-consistency
  2. Ensure that there is a custom-check step implemented which uses that package.
  3. If you run yarn custom-check and any of the problems are present from the Types of issues that arise (not a complete list) section then it needs to fail.
  4. It needs to report failures using the existing conventions for all the other custom-checks we have in place.
  5. There has to be a separate npm script in the root package.json which allows contributors to run just this one check by itself as well. Call it tools:check-dependency-version-consistency