proposal: add support for traversing transitive dependencies (with levels + their release notes)

[Dentrax]

Abstract

Recently I saw cri-o's beautiful changelog (Jump to dependencies section) that prints any dependency modifications such as add, change, remove.

Example Add:

• github.com/go-logr/stdr: v1.2.0

Example Changed:

• github.com/go-logr/logr: v1.2.0 → v1.2.1

Dependency changes are exactly what we would want to see before upgrade anything. It would be great to have a dependency parser and printer in tree structure. And in this proposal, I would like to extend this feature a bit further by introducing a configurable level to traverse all nested transitive dependencies.

Proposal

Introduce new flags to customize dependency changelogs

• --enable-transitive-dependencies: Boolean. Default False. Enables our brand-new transitive dependency scanning feature.

Added:

• github.com/go-logr/stdr: v1.2.0

Changed:

• github.com/go-logr/logr: v1.2.0 → v1.2.1

If dependency newly added, URL should point out to /tree/<TAG>. If dependency changed, then URL should be /compare/<OLD_TAG>...<NEW_TAG>.

• --dependency-level: Integer. Default 1. How many levels of depth can git-cliff go down.

The example above uses level 1. If we set level 2, we should get the following:

Added:

• github.com/go-logr/stdr: v1.2.0
• • github.com/go-logr/logr v1.2.0

Changed:

• github.com/go-logr/logr: v1.2.0 → v1.2.1 <NO CHANGES ON GO.MOD SO SKIP>

• github.com/onsi/gomega: v1.11.0 → v1.16.0

• • github.com/golang/protobuf: v1.4.3 → v1.5.2
• • +github.com/golang/protobuf: v1.4.3
• • -github.com/golang/protobuf: v1.4.3
• • ...
• • <+PREFIX IF NEW DEPENDENCY ADDED>
• • <-PREFIX IF ANY DEPENDENCY REMOVED>

Removed:

• github.com/go-logr/stdr: v1.2.0 <WE DONT NEED TO PRINT TRANSITIVES SINCE WE DELETED IT>

If we set level 3, then we expect it should go one step further. Also, It should go as many levels as it can go.

Note: Flag names can be changed later on; this these are just placeholders for the proposal.

Concerns

• To avoid endless recursive loops, we may think to mark dependencies as "visited".
• I'm also not sure about precedence among add/change/remove. Maybe we should print changes first, then added ones, finally removed ones.
• We can start a PoC with a language and then iteratively support other languages: Cargo.toml, go.mod, package.json, etc.
• Getting release notes may require an API call (Auth might be needed if there are much dependency changes), so we can support GitHub in the first place.

Alternatives

Don't know much about alternative tools.

Additional context

I think this would be a challenging feature to implement. We can discuss further to improve this proposal. Waiting your thoughts!