Bazel can run any toolchain you want, so there is more than one way to use it with Angular. See Alex's post Angular ❤️ Bazel update for a longer explanation.
Architect: The first approach is the simplest: use Architect (aka. Angular CLI Builders). This is the build tool inside of Angular CLI, so your existing application will continue to work the same way, and you can still get support from the Angular team. This may be a good choice if your goal is just to include an Angular app in a full-stack Bazel build that includes your backend, and making the Angular build&test faster is not important for you.
However, it has the worst performance because the level of incrementality is only as fine as how many libs your application is composed from. Bazel can only make a build more parallel and incremental if you express a wider dependency graph to it.
Google: This toolchain is what we originally advertised as "Angular Buildtools Convergence" (ABC). It is based on Google's internal toolchain for building Angular, and has good performance characteristics. However it is harder to migrate to, because it doesn't have good compatibility for existing applications.
The example has its own guide: examples/angular
View Engine: If you're stuck on the older Angular compiler/runtime before Ivy, called View Engine, then your options are more limited. We don't support Angular 9 + View Engine + Bazel.
Custom: Bazel is excellent for advanced use cases where you need to customize your toolchain. Take any off-the-shelf tools, follow their README's to call their CLI, and assemble them together in a custom way. This lets you take advantage of the latest JS ecosystem innovations without waiting for tooling vendors to assemble it all together for you.
Similar to the explanation above for Angular, Bazel is agnostic to what tools you choose to run on your project. However, the benefits of using Bazel are unlocked as you adopt it as your build system. We think the following examples show a typical migration of adopting Bazel:
create-react-app: If you run
create-react-app, it will install a build system called
As a first step into Bazel, you can simply ask Bazel to wrap the existing build system.
This guarantees compatibility with your current code, and if your objective is just to include a frontend app into
a bigger full-stack Bazel build, this might be the final step in the migration.
However it will run
react-scripts as a single Bazel action, which means that you gain no incrementality benefit.
So we expect for most applications this is just a first step.
The create-react-app example shows how this will look. We suggest reading the README in that example, and also look at the commit history to that directory as an illustration of how we started from create-react-app and added Bazel bits.
react-scripts-like: As a next step to make our Build more incremental and performant, we can replace the
react-scripts build system with Bazel, but preserve compatibility as much as possible by having Bazel run
mostly the same tools with mostly identical configuration. We continue to transpile TS to JS using Babel, for example,
but we do it in a build step before invoking Webpack, just using the Babel CLI.
This is a good middle ground to get some benefits from Bazel while staying on the same supported tools as react-scripts.
TODO(alexeagle): build an example illustrating how this looks
custom: If you really know your JS build tools, Bazel is the perfect way to assemble all the myriad individual tools into a custom toolchain. This allows you to unlock any part of the JS ecosystem without waiting for it to be integrated for you by maintainers of a project like create-react-app, who have a very high bar for adding features since the maintenance and support burden falls on them. However you'll need to understand both the tools as well as Bazel to successfully build your own toolchain.
There is a basic example at examples/react_webpack but it needs a lot more work to show everything that is possible!
We don't have a dedicated example yet, but Vue has been known to work. Follow https://github.com/bazelbuild/rules_nodejs/issues/1840 for an example.
None yet, please file an issue if you need this.
There is a dedicated example for Jest: examples/jest
We have done some early work to run Cypress under Bazel. Follow https://github.com/bazelbuild/rules_nodejs/issues/1904 for an example.
Example at examples/webapp has a simple
Karma and Protractor
See Protractor usage in examples/app
The example at examples/webapp uses Rollup, and produces an app with ES5 and ES2015 variants ("differential loading") that gives faster loading in modern browsers without dropping support for legacy ones.
The example in examples/parcel shows how to write a custom rule, it happens to use the parcel binary to build. It's a very minimal example but might be enough to get you started.
LESS, Sass, Stylus
See styles directory inside the examples/app example.
Most of the examples show TypeScript usage. Also look in packages/typescript/test for lots of handling of edge cases.
The Kotlin language can compile to JS. The result has a very large stdlib JS payload, so we don't recommend this for most uses.
Example at examples/kotlin
Google Closure Compiler
rules_closure is a whole-cloth approach to using Bazel if you're fully bought-into the Closure ecosystem.
examples/closure shows a very simple way to call the closure compiler without jumping into that ecosystem.
Protocol Buffers and gRPC
Note: this is considered a "labs" feature in rules_nodejs, so support and stability are not great. gRPC is still a WIP.
Bazel Persistent Workers
If you want to speed up Bazel by keeping some tools running warm in the background as daemons, there's a good readme in the examples/worker