rules_cc VS rules_nodejs

Not that I'd recommend it, but if you symlink your system library into the bazel build area, as long as your sandboxing setup don't hose you (or you just turn it off), bazel will track system tools/library in the same way as everything else.

Bazel's rules_cc even has a system_library.bzl you can import a `system_library` from that automates this for you. https://github.com/bazelbuild/rules_cc/blob/main/cc/system_l...

I'd still recommend building everything from scratch (and understanding the relationships and graph of your dependencies), but if your build isn't that complicated and you want to role the dice on UB, this isn't that hard.

As an aside, the most galling part of bazel's cache key calculations has to be that it's up to the individual rules to implement this how they see fit. The rules native to bazel written in java vary wildly compared to starlark-written rules. On thing you (or someone in your org) end up becoming pretty comfortable with while using bazel in anger is RTFC.

I found several associated issues and a closed PR that supposedly solved this issue. However, it seems that cc_rules has undergone several changes and this PR likely wouldn't function.

Bazel is just the infrastructure to run webpack. You'd need to do some work to make webpack's state be cacheable (I dunno what options and such it has for this, maybe it's already there as an option). But if you're looking at Bazel for JS work you probably just want to use the existing and maintained rules for it: https://github.com/bazelbuild/rules_nodejs It's been a while since I last looked at it but I don't think it has any caching for webpack.

> Is Bazel designed in a way that make it impossible to do JS monorepos well?

Not impossible, but you really need to go all in with it and follow its conventions and practices. See this for the main docs: https://github.com/bazelbuild/rules_nodejs

One thing in particular that doesn't work well in the bazel world is doing your own stuff outside its BUILD.bazel files. If you're used to just npm install and jam some code in your package.json scripts... that doesn't usually work in the bazel world. If you have a lot of logic or tools in your build you'll likely need to go all in and make bazel starlark rules or macros that recreate that logic. Nothing is impossible, but expect to spend time getting up to speed and getting things working the bazel way.

I am using Bazel with rules_nodejs and Webpack. There's an example here.

It is probably possible to build Angular with ts_project(), however you'd need to manually manage the compiler (Angular has its own) and tsconfig (Angular needs special options). ts_library() does a lot of this for you, so I think it would probably be easier to use that than to force yourself onto ts_project(). The canonical Angular example uses ts_library() FWIW: https://github.com/bazelbuild/rules_nodejs/tree/master/examples/angular

https://github.com/bazelbuild/rules_nodejs

Nx is widely used in the Angular community. The Angular team at Google had plans to add Bazel support to the Angular CLI for many years, but the plans didn't materialize. The key folks (e.g., Alex Eagle) working on the effort left Google. Google employees no longer maintain rules_nodejs.