Two years ago, we launched the semver-stable release of Aspect's JavaScript ruleset for Bazel, rules_js. Today I'm happy to announce that we've wrapped up development on the 2.0 release, and it's time to upgrade!
While you're poking at your Bazel setup, we also encourage users to try our monorepo developer platform, Aspect Workflows. This is the easiest way to achieve Bazel's promised speed and cost savings benefits in your Continuous Integration and Delivery pipeline. It includes Remote Cache and Remote Build Execution, along with a host of other features. Talk to us if you'd like to run a free month-long trial to compare with your current setup.
What's new
pnpm is the package manager we ported into Bazel. We now support pnpm version 9. We also now support the onlyBuiltDependencies
option, which improves security by disallowing arbitrary code execution of postInstall
lifecycle hooks from packages you depend on.
Previously to "link" one library in your monorepo to the node_modules
of some application, you needed an npm_package
rule in the middle, regardless of whether that library was intended to be published outside the Bazel build. With rules_js 2.0, a js_library
target may be directly linked into consuming packages. This is faster, as it avoids some copying. It's also more compatible, fixing an issue with peer dependencies of first-party packages. And, it avoids an undesired "eager type-check" where .d.ts
files in the npm package target triggered TypeScript to run, even if the .js
files could be produced by a faster transpiler.
ESLint is the de-facto linter for JavaScript and TypeScript code. Previously users had to grab the js_binary
target from the eslint
package, and then wire up their own method for executing it. With Aspect's rules_lint in 1.0 release candidate, we can confidently recommend that you use the eslint support we provide, which includes the ability to treat lint warnings as code review comments, rather than forcing them to be treated like errors. It has the added benefit that you can lint most other languages too, using a single configuration and with the same developer workflow.
For Docker container users, we've updated js_image_layer
to produce 5 individual layers, with your application code only in the upper-most layer. This improves time to docker push
since only the changed layer has a novel digest and needs to be uploaded to a remote registry.
We've made some performance improvements too, that will make Bazel's analysis phase faster. We optimized some starlark codepaths and data structures, and also reduced the size of the depset we use for representing third-party libraries. npm_translate_lock
runs faster too.
In addition, this release is simply our chance to clean up a ton of TODO's from the codebase. As we've maintained rules_js over the last two years, we kept our promise of semver compatibility, which meant a lot of changes had to be deferred until now.
Keeping the codebase clean makes it more mutable, so we're able to continue our long-term support commitment.
How to upgrade
Aspect has upgraded many of our clients, and found that it's pretty quick and painless in most cases.
We have written a comprehensive migration guide. Please give us feedback in #javascript
on Bazel Slack if you run into anything missing, and we'll be able to improve the migration guide for others. We don't want anyone stuck on rules_js 1.x - that increases our support burden!
Finally, if your company is getting value from our OSS rules, consider using the Sponsor button on the repo, or add your adoption testimonial to https://github.com/aspect-build/rules_js/discussions/1000.
Thanks for being valued Aspect customers!
- Love from the rules_js maintainer team