Monorepo with several connected Bazel Workspaces - are there any "traps" to consider?

Question

I'm working in an organization that is moving towards a Monorepo (C/C++). In short: we are considering having several connected Bazel Workspaces within this Monorepo, using local_repository. This is in contrast with joining the original components into one big Workspace. If someone has practical experience with this, or know what the original design intention is, that would be incredibly helpful for us.

The major motivation for this is developer happiness. We already have long paths in C++ include statements, Bazel labels, etc. and I have found no good ways of creating "modules" where we can reduce these paths to being relative to the module root instead of the repository root. Looking online, I haven't found any examples of people splitting their repository into several Workspaces, so I get a feeling that there are good reasons to avoid it.

Is it advised against having several Workspaces corresponding to the original components? If so, why? I've made a proof-of-concept that shows that building works just fine but I can imagine that auto-completion, querying and some other features don't work well over Workspace boundaries.

As I said, I have found very little information about this online. There's Single or multiple bazel WORKSPACE should be used for monolithic repo? but the accepted answer glosses over the advantages of having several Workspaces and doesn't go into detail of why it would be a bad idea to do so.

question from:https://stackoverflow.com/questions/65901910/monorepo-with-several-connected-bazel-workspaces-are-there-any-traps-to-cons

Answer 1

I'm assuming you're only planning to support builds in one "top-level" WORKSPACE. Otherwise, you have to duplicate all the dependencies (or put them in a big macro that gets used in each), and they each have their own output root (which includes the action cache).

The big developer unfriendliness issue I see with that is that bazel build (and other commands) look for the first WORKSPACE they find going up the directory tree. It's similar to how git looks for a .git folder. That means running a bazel command from the wrong directory produces weird errors when it finds the "wrong" WORKSPACE. You can mitigate that by making all the other WORKSPACE files look like this:

fail("Do not build from this directory, try the root folder instead.")

At least it's a clear error then, but it's still annoying to have to cd before running a build.

Have you considered doing includes = ["."] for all your rules, and only creating BUILD files in the module root directories? That should let you do the include paths the way you're describing, while keeping it all in the same workspace.