That said, the major sore point with Bazel for me is the general lack of expertise about how to work with it sanely. Depending on what part you’re looking at, it’s somehow both “too opinionated” and “too flexible” at the same time.
I think it will capture a big chunk of the mindshare for build systems over the next few years, and you’ll see more and more of it. Over that time, people will develop the expertise and best practices for different development problems.
For managing third-party dependencies specifically, Bazel gives you a ton of options, including options that only really make sense for huge orgs like Google. Google vendors their third-party libraries directly into the monorepo. If that doesn’t make sense for your org, Bazel lets you work with external Git repos, with artifact repositories, with package repositories like NPM, or with tools like pkg-config.
The thing that makes this hell, right now, is that few people how to use it well and the documentation is rough. I’m personally very happy with it, even for small codebases, but I’ve used it a lot.
Also building distributable packages with bazel never seemed to work well due to the constant aliasing of so files. Things that would work in the direct bazel build would fail in packages and vice versa so now we had even more pain.
Trying to suck up just header files and multiple so files was always arcane bullshit as well.
We did work with git and other such functionality, but if you had to build a package from another build system to bring into bazel there were always annoying pain points.
Also bazel managed to bring in implicit dependencies in our system so that clearly isn’t something bazel
magically handles but was rather a product of your expertise.
After reading build systems ala carte I am just more convinced bazel is not the build system that I would really ever need. I’m not sure that build system exists yet to be honest :). But in the work I do other systems solve my problems better.