Try Bazel’s opt-in preview in Angular CLI

In Google we build all our software with a tool called Bazel. We’ve been using it for the past over 12 years to build projects with any size — from small internal apps, to large applications such as Gmail, Google Drive, and Google Cloud Console.

Thanks to its properties — hermeticity, parallelism, and incrementality, Bazel enables fast builds, which are proportional to the changes that we’ve made, rebuilding only the artifacts that are affected by the updated files.

For the past 2 years, we’ve been working on enabling Angular developers outside of Google to use the same workflow and make their builds faster. In Angular CLI version 8, we’re happy to introduce an opt-in Bazel preview which will allow you to use Bazel transparently, using the same Angular CLI commands you’re used to! Below you can find the official announcement of the opt-in preview from ng-conf by Alex Eagle:

The Bazel Opt-In Preview Is Here

Current status

We’ve been working closely with the Bazel team at Google to decrease the file size of the Bazel’s binary and improve its integration with the external Node.js ecosystem.

Over the past few months, we introduced the CLI builders, which allow us to change the implementation of some of the built-in Angular CLI commands and create new ones. With @angular/bazel, we created new implementations of the ng build, ng serve, and ng test commands which internally invoke Bazel. This way, we can use the command-line interface we’re already familiar without having to know anything about the build tool the CLI uses under the hood!

Today we support standard Angular CLI projects, route-based code-splitting, Sass, third-party dependencies, and more! Here are some of the capabilities that you can expect if you try the opt-in preview:

• Production and development builds. Since Bazel enables the incrementality of the Angular compiler, for both production and development the Angular CLI will use Ahead-of-Time compilation.
• Hidden BUILD.bazel files for small projects. Developers using Bazel describe their build process in BUILD.bazel files (you can think of these files as gulpfile.js or webpack.config.js), where each BUILD.bazel file defines a package and each package defines a separate compilation unit. For small projects, we automatically generate the build configuration and do not expose it to the developers using the Angular CLI
• Unit testing with Karma, Jasmine and end-to-end testing with Protractor

In 2019, we’ll focus on improving the feature set that the Bazel functionality in the CLI provides. Some of the limitations of the opt-in preview that we’re working on are:

• Supporting the complete set of features that the Angular CLI provides (PWA, universal support, app shell, etc)
• Support of third-party modules distributed without a UMD bundle. Currently, the development server of Bazel supports limited amount of module formats because of optimizations it does to speed up the page reloads in development. This constraint could be overcome using custom module loading configuration with require.js. In the future, we’ll work on supporting a wider range of module formats by default.
• Performance improvements. Bazel is highly optimized for large applications with hundreds of thousands of lines of code. We’re working on scaling it down to support instantaneous builds for any project size. Soon we’ll land better integration with npm, which will lead to significant improvement of the initial build time.

What else can I expect from Bazel

Some of the attractive features that Bazel enables are:

• High-level of parallelism — Bazel can statically determine your build graph and execute multiple tasks in parallel. This will utilize all the cores on your CPU (if necessary), making your build fast. For unbounded level of parallelism, Bazel lets you run your build in the cloud. For the purpose you can use GCP or your on-premise buildfarm.
• Build caching — because of its hermetism, Bazel provides reliable caching which lets it rebuild only the assets that have changed. The caching can be either local, or remote! The power of the remote caching comes when we share it across your entire organization and CI. Once we build given artifact, our colleagues (or CI), can directly reuse it from the remote cache unless it has changed.

All these features you can try today by manually managing your build configuration.

How do I opt-in

Before trying the opt-in preview of Bazel, make sure you’re using Angular CLI version 8 or above.

To try the Bazel integration with the Angular CLI with a new project, you can provide a custom schematics collection:

Once you create the new project with the Bazel schematics you and run ng serve or ng build the same way you’re used to! There are a few differences:

• ng build produces a production build by default, so no need to specify the --prod flag
• The CLI will output the production assets under the directory dist/bin/src/prodapp

Keep in mind that the first production build may take a little longer than expected, until Bazel populates its cache. Bazel will also perform some additional operations related to an ongoing effort for better interoperability with npm that we’re going to introduce soon.

For more information, check the Bazel guide on angular.io.

Give us feedback

We’re focused on providing the capabilities of the Angular CLI that you know today, but with faster, incremental builds using Bazel. We’re working to expand the supported feature set until we reach parity with the current functionality of the CLI. Until then, if you face issues with any of the supported features, open an issue on GitHub or sent your feedback to devrel@angular.io.