This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.
Message originally sent by slack user U73M23EQ2G8
We have started moving pieces of our monolith into packages and one feature that I wish were available is for it to be configurable for violations back to the root to be non-breaking. I think this has been the most frustrating part of making packages, people forget to update todos when pushing to CI so we end up spending extra cycles fixing this. We would still want inter-package violations to happen since those should be dependencies, but we have a long road to splitting up the root and this is adding developer friction. Thoughts?
If you are specifically talking about dependency violations you can use the ignored_dependencies key in the config of a package to clarify that you are currently not focussed on these violations
that is pretty much what I would have wanted, like being able to do an ignored_dependencies: . but that PR was closed, will catch up on the conversation in the PR next week, thanks!
You can have all packages declare a dependency on the root package (".") and don’t enforce dependencies on the root package itself. That should do it, if I understand your problem correctly
I also found in these cases that it is quite beneficial to look at why packages depend on the root - most of the time it‘s for libraries, in which case it helps to make lib a separate package, as I propose in https://simplexity.quest/posts/2023-12-23-lib-is-for-libraries
There may also be things in app that see a lot of reuse; again, it might make sense to separate them into a package that is OK to depend on, even if that’s temporary.
That would give packages less reasons to depend on the root package.
I have been telling people not to worry too much about references back to the root, that they should be seen as candidates for extraction and not blockers