Closed sydneypemberton1986 closed 1 year ago
Hi Sydney, thanks for your message! Sounds really interesting what you're doing.
My immediate reaction is that it's possible you could achieve your aims in a simpler way, but I might be missing something.
The fundamental requirement, which is to fail if the number of disallowed imports increases, is probably better done by having a passing contract that contains ignored imports. If you commit your contract to version control, then any PR that introduces a new layering violation will start failing (unless the commiter also adds an ignored import). This makes it easy to see whether or not things are getting worse.
If you want to make further tooling around this, there is actually a Python API for reading the contracts. You can use this for, say, recording a metric of the number of ignored imports in your contract - or even a custom Github action that prevents merge if the number increases.
Does that help?
Thanks. I'll close this since it's not really actionable and I responded in my PR..
Hey folks!
First off, thank you for writing such a wonderful tool!
I work for findhelp.com and we just had our 2023 hackathon, in which we worked on leveraging import-linter to create a Github Action to ensure that the modular structure of our architecture is not degraded by pull requests.
We ended up writing our own custom Contract, which was good enough for the hackathon to get a working proof of concept. But now we want to make a more complete offering and we wanted to get your feedback on the direction we are going, and if anything we are working on would be useful pull back into the import-linter itself.
Our codebase was designed to be a layered architecture but that was not enforced so it would not make sense to just hook the return code of pass or fail into our CI/CD pipeline. Instead we want to fail a build if the number of disallowed imports increases. So the first thing we did was go in and change the output to machine readable JSON so we could parse out the number of failures.
Furthermore, we are slowly working on splitting our architecture into "macro services". This means that a simple layered contract was insufficient for us, but instead we needed to implement a graph of allowed imports.
We also had a need to reduce various disjoint modules into conceptually unified modules. For example:
Finally, we wanted to be able to see the current state of the codebase, or possibly even produce an animation of our modular structure improving over the history of the project.
To solve these issues we are working on writing a Contract that looks a bit like this
Furthermore, since the data we are going to be using to specify these inputs is complex, we are also playing with a JSON configuration file format, something like this:
What do y'all think? Are we on the right track? Is our approach sound? Is anything here useful to port to your project?