tree 89921477e2fb1bee264f8181881320f038617d32
parent eeea2daa520080c7c30b57cba6f1c1b3bec17aff
author David Ostrovsky <david@ostrovsky.org> 1784974201 +0200
committer David Ostrovsky <david@ostrovsky.org> 1784984635 +0200

Bazel: Bump rules_js, rules_ts and rules_nodejs

Update the JS ruleset stack: aspect_rules_js 3.1.2 -> 3.2.3,
aspect_rules_ts 3.8.8 -> 3.9.2, rules_nodejs 6.7.4 -> 6.7.5, and adapt
the tree to what the new versions require and enable.

The rules_ts options validator now resolves outDir through the tsconfig
extends chain and rejects the inherited yarn/IDE outDir
(../../.ts-out/...), which escapes the Bazel package. Override it in the
bazel tsconfigs, kept in sync with the out_dir attributes the ts_project
targets already carry.

rules_nodejs 6.7.5 reads the node version from .nvmrc
(node_version_from_nvmrc), so the version is pinned in one cross-tool
file that nvm, editors and CI honor as well -- previously the yarn dev
flow had no node pin at all. Versions newer than the ruleset's built-in
table are auto-fetched and recorded in MODULE.bazel.lock. This retires
the hand-maintained node checksum dict, the per-platform use_repo
boilerplate and the unused root alias of the pnpm extension (rules_js
resolves its own pnpm; the npm_translate_lock update machinery never
consumed the root alias).

The bundled pnpm moves to 10.34.5, whose import marks git-hosted tarball
resolutions with gitHosted: true (10.34.1 lockfile schema). Whether it
also records an integrity field for such tarballs depends on the local
store state: a cold store downloads the tarballs and emits integrity, a
warm store omits it and strips it on re-import -- same version, same
inputs, different lockfile. Reproducer:
https://github.com/davido/pnpm-codeload-repro, filed upstream as
https://github.com/pnpm/pnpm/issues/13338. The committed lock is the
warm-store form, consistent with the action caches below.

That nondeterminism broke CI: every fresh checkout re-ran pnpm import
(cold) and failed with "pnpm-lock.yaml file updated". The root cause is
that the npm_translate_lock action caches were gitignored, so
update_pnpm_lock could never see that the lock is current. Check the
.aspect/rules/external_repository_action_cache files in, as the rules_js
documentation prescribes -- the action cache "persists the state of
package and lock files that may effect the pnpm-lock.yaml generation and
should be checked into the source control along with the pnpm-lock.yaml
file" ("update_pnpm_lock" in
https://github.com/aspect-build/rules_js/blob/main/docs/pnpm.md): with
matching caches the import is skipped entirely and CI no longer depends
on pnpm's store-state behavior.

This stack also pulls in aspect_tools_telemetry, which reports ruleset
usage with repo and user fingerprints at module-resolution time; opt the
whole tree out via ASPECT_TOOLS_TELEMETRY=-all in .bazelrc.

Release-Notes: skip
Change-Id: I018b2e4754a921a69b6004ca78c38dbf08bd7539