Bazel rules for js
EXPERIMENTAL this code is currently pre-release and not subject to any stability guarantee. It could be archived or there could be major breaking changes.
This ruleset is a high-performance alternative to the
build_bazel_rules_nodejs Bazel module and
accompanying npm packages hosted in https://github.com/bazelbuild/rules_nodejs.
The common layer here is the
rules_nodejs Bazel module, documented as the "core" in
rules_js does! It's a completely different approach to making JS tooling work under Bazel.
First, there's dependency management.
build_bazel_rules_nodejsuses existing package managers by calling
yarn installon a whole
rules_jsuses Bazel's downloader to fetch only the packages needed for the requested targets, then mimics
pnpmto lay out a
Then, there's how a nodejs tool can be executed:
build_bazel_rules_nodejsfollows the Bazel idiom: sources in one folder, outputs in another.
rules_jsfollows the npm idiom: sources and outputs together in a common folder.
There are trade-offs involved here, but we think the
rules_js approach is superior for all users,
especially those at large scale. Read below for more in-depth discussion of the design differences
and trade-offs you should be aware of.
Need help? This ruleset has support provided by https://aspect.dev.
From the release you wish to use:
copy the WORKSPACE snippet into your
The authors of
rules_js spent four years writing and re-writing
We learned a lot from that project, as well as from discussions with Rush maintainer @octogonz.
There are two core problems:
- How do you install third-party dependencies?
- How does a running nodejs program resolve those dependencies?
And there's a fundamental trade-off: make it fast and deterministic, or support 100% of existing use cases.
Over the years we tried a number of solutions and each end of the trade-off spectrum.
Installing third-party libraries
Downloading packages should be Bazel's job. It has a full featured remote downloader, with a content-address-cached (confusingly called the "repository cache"). We now mirror pnpm's lock file into starlark code, then use only Bazel repository rules to perform fetches and translate the dependency graph into Bazel's representation.
See the design doc
Running nodejs programs
Fundamentally, Bazel operates out of a different filesystem layout than Node. Bazel keeps outputs in a distinct tree outside of the sources.
Our first attempt was based on what Google does: monkey-patch the implementation of
NodeJS itself, so that every resolution can be aware of the source/output tree difference.
The main downside to this is compatibility: many packages on npm make their own assumptions about
how to resolve dependencies without asking the
require implementation, and you can't patch them all.
Unlike Google, most of us don't want to re-write all the npm packages we use to be compatible.
Our second attempt was essentially to run
npm link before running a program, using a "linker".
This was largely successful at papering over the filesystem layout differences without disrupting
execution of programs. However, it required a lot of workarounds anytime a JS tool wanted to be
aware of the input and output locations on disk. For example, many tools like react-scripts (the
build system used by Create React App aka. CRA) insist on writing their outputs relative to the
working directory. Such programs were forced to be run with Bazel's output folder as the working
directory, and their sources copied to that location.
Our third attempt is here in
rules_js, where we take that react-scripts-prompted workaround to the
extreme. We always run JS tools with the working directory in Bazel's output tree.
We can use a
pnpm-style layout tool to create a
bazel-out, and all resolutions
This third approach has trade-offs.
- The benefit is that very intractable problems like TypeScript's
rootDirsjust go away. In that example, we filed https://github.com/microsoft/TypeScript/issues/37378 but it probably won't be solved, so many users trip over issues like this and this. Now this just works, plus results like sourcemaps look like users expect: just like they would if the tool had written outputs in the source tree.
- The downside is that Bazel rules/macro authors (even
genruleauthors) must re-path inputs and outputs to account for the working directory under
bazel-out, and must ensure that sources are copied there first.