Skip to main content
  • accidental dependency edges or network accesses
As a monorepo “gardener”, you’ll constantly fight against accumulation of undesirable things that interfere with proper operation. This is just like weeds which compete with the plants in a garden that you meant to grow. Weeds are easy to pull out when they are tiny sprouts, but require a lot of work once the roots take hold. The same is true for monorepo maintenance - as a bad pattern gets adoption, it will have dependencies and coupling that make it much harder to remove. The ideal solution prevents these being checked in at all. The next best is to warn in a code review that a bad pattern is being introduced. Ultimately you’ll also need practices for detecting them, such as scanning user feedback, and then a culture of good hygiene where engineers and their managers agree on pulling weeds early.

​
Prevent build and test actions from accumulating dependencies on the network

This is easy to prevent early in a repository, but very difficult once engineers have depended on lax rules! Bazel’s test sandbox can prevent tests connecting to the network: --sandbox_default_allow_network=false. Individual test targets can be allowed with the requires-network tag. To prevent arbitrary fetches from the internet is harder. We suggest setting up iptables-based network blocking on CI workers.

​
Prevent accidental dependency edges

You can’t build a service with high reliability with a dependency on one that has low availability. The same is true for dependency edges in the graph. If engineers from an important, business-critical service have a dependency within the monorepo on poorly maintained library code, then the library developers are stuck trying to meet an SLA they cannot. They never meant to sign up to support the needs of this service using their library. Bazel’s visibility system is an excellent way to force users to first “sign up” before they depend on your library (or, if you have a service with a client library, prevent them from using the service). A good pattern is for the visibility to start out minimal, just for the current project. Then add a package_group when you need to expand the visibility. Applications that want to depend on the library have to first send a PR to add their packages to that group, and the code review process should require a review from a library maintainer. This is your chance to discuss whether the dependency should be allowed.