Reimplementation of python for build file language? No thanks.
Reimplementation of package managers? No thanks.
Reimplementation of Docker? No thanks.
It’s just another thing to learn, worry about, and discover bugs in rather than something that just works. I already know how docker, yarn, and python work and that stuff works well, why are we boiling the oceans recreating and relearning all of this just to do it the “Bazel” way?
What a waste of time and energy!
On top of a that, everyone on my team had to learn skylark, their rules for docker, their rules for node, their... I’m exhausted just thinking about it...
Why bother unless you’ve got google size? It’s good software written by smart people, but I know I made a mistake in choosing it for our build solution.
I've used bazel in a different environment (C++) and it has been amazing (compared with other C++ build systems).
Another comment below mentioned to stay away from bazel for anything else other than C++ (and maybe Java).
I've also seen it used with java android apps.
* Bazel needs gigabytes of memory to run;
* It needs minutes to bootstrap (which it will every time, because you don’t want a multi-gigabyte-sized daemon running around);
* It breaks every second day. If you are building version X of $something, you better go and get the exact version of Bazel that the developers of $something were using when tagging X;
* And when they fail to build there’s no chance you will be able to figure it out without spending days on it.
Don’t use Bazel unless writing code that only you yourself can maintain is your goal.
Getting it to work can sometimes be a pain in the rear (although I'm not sure other systems fare much better). I'm still trying to figure out some missing header file errors... some are obvious and easy to fix, but but some are confusing as heck. I also hate the fact that I have to specify header files redundantly, once in the source file and once in the build tool.
Their documentation can also be painful to quickly find stuff in (e.g. try finding how to display the command line options passed to the C++ compiler); sometimes some flags are just spread out in the prose rather than in the normal table format. Their @// notation is not exactly intuitive; I'm still not sure I fully understand it.
And lastly, there are lots of rough edges, e.g. there's no way to call an existing Makefile and pass it conditional compiler options, so good luck sharing your compile flags across the entire codebase in an elegant manner.
For a Go project which the whole build command is a single line of `go build`, it takes lots of config files and configuration, and tweaking till you get the exact same result. Only till there is an update and the whole build crashes and you have to figure it out why.
To me m, Bazel is a great tool for Google or a project at the scale of Google projects. It is beneficial if you can benefit from distributed builds and caching layers. Only for a project big enough that those could make a difference.
But for all other projects, Bazel, felt like brining an 18-wheeler to go to grocery shopping.