Feedback request: codechecks wrapper for dependency-cruiser

[MichalZalecki]

I'm working on dependency-cruiser integration. It will allow for a custom set of rules but I wanted to provide a value for people unfamiliar with the dependency-cruiser by providing some predefined rules. I welcome any feedback.

https://github.com/MichalZalecki/codechecks-dependency-cruiser

[krzkaczor]

I like it! 🎉 dependency-cruiser is such a powerful project that somehow slipped under my radar (literally 😆). It could replace ban-dependency-codecheck that I created in a hurry to cover my needs. Here are my thoughts.

Currently codechecks-dependency-cruiser is a simple wrapper for dependency-cruiser package which is great but it results only in increased visibility to the end-user ie. see failure reports on GH rather than CI pipeline. I mean DC could be part of CI pipeline and the result for the end user would be more or less similar.

Now, I think that there is much more potential here.

First of all, you could upload a graphic representation of the dependency graph (generated by DC) and attach it to github. You can use saveFile and getArtifactLink for that. It already achieves something that is not possible to display as part of CI console output.

Secondly, I think this codecheck could grow into general dependency management powerhouse. For example:

• it could track the amount of deps (both direct and undirect) and display info like: 2 new direct and 15 undirect dependencies added in this PR. Careful!
• it could pull info about new deps from NPM as well and attach it to a detailed report. Something like

new dependency is-promise
downloads weekly: 135k
Description: Checks if object is a promise.

• force using npm or yarn? Fail if a yarn/npm lockfile is pushed (do not mix lockfiles).
• validate changes in lockfiles. This is really something that I need for open source projects. Imagine a PR updating a deps from a untrusted party. Changes in package.json are easy to validate but changes in lockfiles are often impossible to verify by human (too many changes, hashes of packages rather than versions). I thought a lot about this lately and this would be such a timesaver.

Of course all of these could be separate codechecks as well :D But I think that maybe combining them together is not a bad idea 🤔