Pnpm v10 and rules_js: Better Alignment and Improved Build Determinism

Pnpm v10 was released earlier this year. After some initial issues release 10.11.1 now fully passes regression tests with rules_js.

This release brings notable improvements in hermeticity, performance, and reliability, aligning pnpm more closely with the expectations and requirements of Bazel-based workflows that use rules_js.

(Only) Built Dependencies

Since pnpm v9 rules_js has required packages with build steps to be manually declared in the pnpm.onlyBuiltDependencies field of package.json. Now pnpm v10 has the exact same requirements as rules_js, see pnpm #8897 (as well as #7710 and #7716 for more background).

Explicitly declaring which packages require a build step improves determinism and hermeticity in both pnpm and rules_js. This allows rules_js to model Bazel build actions without first needing to download and inspect package contents.

This change was followed-up with pnpm.neverBuiltDependencies (#8958) in pnpm 10.1 to suppress pnpm install warnings about packages containing install logic without being listed in pnpm.onlyBuiltDependencies.

Secure SHA256 Hashing

Pnpm v10 has switched to more secure SHA256 hashing of content in the pnpm-lock.yaml file, see #8530. Bazel and rules_js already use sha256/512 for integrity checks, and rules_js will continue to align with pnpm lockfiles where pnpm v10 has upgraded to sha256.

Configuration changes

Pnpm v10 has made many other configuration related changed that do not directly effect integration with rules_js, but may effect your experience when upgrading such as:

• default hoisting has changed #8378

• NODE_ENV is now ignored on install #8827

• the @yarnpkg/extensions package was upgraded, this may alter resolved dependencies in edge cases

Catalogs

While actually a pnpm v9.5 feature, pnpm catalogs is a feature worth mentioning again. Catalogs have provided a way to stop repeating version numbers throughout your package.json files and declare a single version for a package in a single location, while keeping fine grained dependencies in your projects.

Catalogs are especially useful in large monorepos where Bazel and rules_js are normally used.

Catalogs are used by pnpm when generating the pnpm-lock.yaml file and does not change the underlying lockfile format, so rules_js supports comes for free.

Final Thoughts

Like pnpm v9 last year, pnpm v10 continues to move toward more deterministic builds that continue to align with Bazel and rules_js, further proving pnpm was the right choice for the Bazel and rules_js ecosystems.

See the pnpm v10 release and followup releases for a full list of changes.