Bazel for Frontend: Introducing rules_js

Photo by Jexo on Unsplash

Bazel for Frontend: Introducing rules_js

Alex Eagle's photo
Alex Eagle
·Jun 15, 2022·

2 min read

At Aspect we've been working on supporting the Bazel build tool in the frontend/JS ecosystem for five years. We started from how Node.js programs are run internally at Google. It worked okay, but to be honest, it was never great.

A few of the problems our users have endured:

  • Too slow to run a full package manager install whenever a file like package.json changes
  • Having separate source and output folders breaks expectations of Node.js tooling. For example, TypeScript required a tricky rootDirs setting to resolve everything.
  • No support for "workspaces" so every package.json had to be independently installed
  • Performance: treating npm packages as directories rather than thousands of files was bolted-on late in the project and hard to adopt.

rules_js solves these problems! There's lots of info in our README: github.com/aspect-build/rules_js. See Greg's benchmarks as well: blog.aspect.dev/rulesjs-npm-benchmarks - note that in the best case scenario, Bazel only needs to install a single npm package if that's the only one in the transitive dependency closure of the requested build/test targets!

The first Beta release of rules_js is out: v1.0.0-beta.0 along with accompanying rulesets for some common tools like TypeScript, ESBuild, SWC, Rollup, Terser, Jest, and Webpack, listed at https://github.com/aspect-build.

So now is a great time to do some prototyping. Follow our migration guide and let us know how we can improve our docs to help you get up and running quickly.

I'll be giving a talk on it next week: events.skillsmatter.com/bazelx2022 and we hope to publish the 1.0.0 final around that time.

Thank you to so many of our partners:

  • Our awesome coworkers at http://aspect.dev for working through design and public API review over the last year
  • Adobe for being an early adopter to help us shake out the bugs
  • Our OSS community for evaluating the design as it has evolved
  • Pete from Rush.js for showing us how pnpm is the perfect fit
  • Ryan Day at Google for pushing us to use npm-native abstractions
 
Share this