The Clippy and Doc tasks declare `outputs: []`, so `pnpm pipeline` caches
their results, keyed on every file in the repository plus `RUSTFLAGS` (and
`RUSTDOCFLAGS` for Doc). Their jobs no longer pass `--no-cache`.
A new `remote-cache` composite action points the pipeline at Vercel Remote
Cache. It runs only in the merge queue and on pushes to main, which also
sign and publish their results, so the Vercel token never reaches pull
request code. The push to main tests the tree the merge queue already
tested, so its Clippy and Doc rows restore the results instead of
recompiling. The action does nothing until the token, team, and public key
are configured.
The credentials live in the remote-cache environment, which only main and
the merge queue branches can use, so a workflow on a pushed branch cannot
read the signing key.
Dylint keeps `--no-cache`: its run on main saves the build cache pull
requests restore, and a cache hit would leave that cache stale.
* chore: update dependencies, Node.js, pnpm, and GitHub Actions
* ci: run the wasm nightly through pnx and dylint through rustup
pnpm 12.11 runs scripts with the toolchain from rust-toolchain.toml first
on PATH, so `cargo +nightly-2026-08-27` reached a plain cargo that does not
know the `+toolchain` syntax. The wasm and runtime-probe builds now run
`pnx --package=rust@nightly-2026-08-27 cargo`, which installs the nightly
with the wasm target, so the rustup install and the job-wide
RUSTUP_TOOLCHAIN go.
cargo-dylint builds its lint library through the rustup proxies, which
pick the nightly the library pins and set RUSTUP_TOOLCHAIN for
dylint-link. Under pnpm it got the workspace's stable cargo instead. CI
now runs `cargo dylint` directly, as `just dylint` does, and the unused
pipeline goes. The pre-push hook, which runs as a pnpm script, puts the
directory holding `rustup` first on PATH for its dylint check.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* ci: bundle the esm loader before the dylint check
`pnpm-deps-restorer` embeds `cas-loader.mjs.inc`, which the prepare
script of `@pnpm/esm-loader` generates. `pnpm pipeline` installed it
implicitly; the direct `cargo dylint` run needs the install as a step.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* chore: update dependencies, Node.js, pnpm, and GitHub Actions
* chore: generate the embedded CAS loader bundle on install
The CAS loader that `deps-restorer` embeds with include_str! was a
minified esbuild bundle committed to the repo. Every enhanced-resolve or
esbuild bump rewrote most of it, and a stale copy failed CI with a
byte-by-byte assertion diff.
`@pnpm/esm-loader` now generates it from a `prepare` script, so every
`pnpm install` that includes the package writes it before cargo builds.
Cargo already depends on that install for `.pnpm/crates`. The package
gets its own esbuild devDependency instead of borrowing pnpm11/pnpm's.
The filtered installs that feed cargo (install-crates and the wasm
release job) now also select `@pnpm/esm-loader`.
Also ignore GHSA-hp3w-g68c-fv3c. sprintf-js has no patched release, and
it is reached only through argparse 1 formatting its own help text.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* chore: write the CAS loader bundle atomically and generate it for wasm CI
An interrupted `prepare` could leave a truncated bundle that a later
up-to-date install never rewrites. Write to a temporary file and rename.
The pnpm-wasm workflow builds the CLI after a filtered install, so it now
selects `@pnpm/esm-loader` too.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* chore: update dependencies, Node.js, pnpm, and GitHub Actions
* fix(deps): hold `@yarnpkg/core` at 4.9.1
`@yarnpkg/core` 4.9.2 was published with `got` declared as a Yarn
`patch:` specifier. pnpm resolves that to a `link:` into a nonexistent
workspace path, so `got` is missing and the TypeScript compile fails
with TS2307 in `@yarnpkg/core/lib/httpUtils.d.ts`.
Pin the catalog entry back to 4.9.1, override the transitive copy that
`@yarnpkg/nm` pulls in through `^4.9.1`, and add the package to
`update.ignoreDeps` so the daily update-lockfile run stops bumping it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Compile the shared Rust CLI for wasm32-wasip1-threads and supply filesystem,
network, process, terminal and cancellation capabilities through a Node host.
Select host implementations at compile time so native builds retain their
native dependency/features and execution paths.
Bundle the WASM runtime in the regular npm wrappers and select it from the
WebContainer runtime marker. Keep Node launchers usable without installation
scripts. Native installation replaces all four launchers with native bytes.
Regenerate shims after upgrades or dependency builds replace Node targets with
native binaries, including before dependent lifecycle scripts run. Preserve
collision winners and publish replacement shims with executable permissions.
Reject non-descendant permission templates and intermediate symlink escapes, validate before creating directories, and avoid path-based cleanup races.
Restore direct native aliases in both version-management implementations.
Retain process cleanup after failed stdin shutdown. Prevent cross-origin redirects from replaying login credentials in both CLI lines, and strip npm-otp from cross-origin WASM requests. Avoid repeated selected-snapshot and removed-bin scans.
Preserve resolution, lockfile, integrity and build-approval behavior. Use an
isolated WASM store with rollback journals and process leases. Patch WASI path
normalization for multiple parent segments and retain that patch in bundles.
Add pinned tooling, release packaging, real-browser workflow and selection
tests, documentation and a release note. Document host limits, including the
Corepack cold-download failure in WebContainer's streaming hash implementation.
Controlled native CLI cases showed no separated slowdown, and the latest
hoisted rebuild and repeat-install fixture improved. Retain the documented
microbenchmark uncertainty and host limitations.
Related to pnpm/tasks#63.
* chore: update dependencies, Node.js, pnpm, and GitHub Actions
* chore: keep `@yarnpkg/core` at 4.9.1
`@yarnpkg/core@4.9.2` was published with a Yarn-only
`patch:got@npm%3A11.8.2#~/.yarn/patches/...` dependency. pnpm locked it
as a dangling `link:`, so `got` was never installed and `tsgo` failed on
`@yarnpkg/core/lib/httpUtils.d.ts` in TS CI / Compile & Lint.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* chore: drop registry mirror URLs from the lockfile
The previous commit regenerated the lockfile with a local scoped
registry override, which wrote non-npmjs tarball URLs for `@pnpm/`
packages and failed the supply-chain check in CI.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Cache the vendored Rust dependencies: rust-cache kept only packages
outside the workspace root, and pnpm vendors crates.io dependencies
inside it, so every Rust job compiled about 950 crates. Rooting it at
pnpm/ and pnpr/ keeps the vendored crates and still drops the workspace
crates, which a fresh checkout rebuilds anyway. Build the Windows
pacquet and pnpr tests once, build both benchmark revisions with thin
LTO, run Garnet on the Node.js 24 chunk that finishes first, and stop
the CI compile step from fixing lint errors.
Tests that need a failed connect dial 0.0.0.0, which Windows rejects at
once where a refused loopback port takes 2 s, placeholder tarballs no
longer point at a .local name that waits on mDNS, git fixtures spawn
fewer processes, the cargo failed-resolution test answers cargo's
underscore lookup, two tests that count metadata requests use their own
cache dir instead of the shared default one, and three publish-wait tests
allow the second probe a deadline race can send.
---------
Co-authored-by: Zoltan Kochan <z@kochan.io>
Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Commit the pnpm-managed Cargo source block. The block is a function of
Cargo.lock, so an install regenerates it byte for byte and the tracked
`.cargo/config.toml` stops reporting as modified after every install. A new
Rust CI step fails if the committed block and the lockfile drift apart.
Cargo now resolves every crate through `.pnpm/crates` and falls back to its
own registry nowhere, so each job that runs cargo needs an install behind it.
Eight did not have one: both cargo-unused jobs, the micro-benchmark, the
integrated benchmark's build and executor jobs, and the three release builds.
The new `install-crates` action gives them one and narrows the JavaScript half
with `--filter pacquet`, which a filter does not do to the Cargo half.
The release builds go through `cross`, which mounts the checkout at
`/project`. pnpm links each crate into `.pnpm/crates` with a relative symlink,
so a store outside the checkout stops resolving under that mount. Those jobs
install into a store inside the checkout instead, on Linux, the one host where
cross containerizes the build at all.
The two workflows that commit no longer discard the block. It is tracked
content now, and a run that changes it should carry the change.
Claude-Session: https://claude.ai/code/session_01Gg6uVUzLw1MniCLC81TQjP
Claude-Session: https://claude.ai/code/session_01HwJS1pAz9HHQpJWEJAiaUu
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
The check that separates a rejected modify command line from an install
that ran and skipped a component watched for any Visual Studio installer
process by name. One already running for an unrelated reason would pass
for the one this step launches, putting the run back on the generic
"clang-cl was not installed" error it is meant to sharpen.
Snapshot the matching process ids before the launch and count only ones
that appear afterwards.
The 12.0.0-rc.11 release failed on both win32-arm64 legs with "clang-cl
was not installed under ...\VC\Tools\Llvm", five minutes after the
Visual Studio installer was asked to add the LLVM and ARM64 components.
`--wait` had been added to that `setup.exe modify` call. Microsoft
documents it as bootstrapper-only: "The --wait parameter can only be
passed into the bootstrapper; the installer (setup.exe) doesn't support
it." We invoke the installer at
`C:\Program Files (x86)\Microsoft Visual Studio\Installer\setup.exe`, so
it rejected the command line and installed nothing. The logs show the
call returning in under a second and no installer process alive for the
whole polling window.
The exit-code check could not catch that. `setup.exe` is a
GUI-subsystem binary, so PowerShell's call operator does not wait for it
and never sets $LASTEXITCODE from it — the value tested was still
vswhere's. Check vswhere's own result instead, where the variable
actually means something, and leave the poll loop as the sole
confirmation that the components landed, which is what it was written
for.
Regressed in pnpm/pnpm#14138; the split into separate CLI and NAPI
matrices is unaffected, it only doubled the number of legs running the
step.
The Rust release built the CLI binary and the NAPI addon back to back in
one matrix leg per target. The two are compiled under different Cargo
profiles — `release` for the CLI, `napi-release` for the addon, which
must keep `panic = "unwind"` so a panic reaching the FFI boundary becomes
a JS exception instead of aborting the host node process. Different
profile means a different target directory, so the two builds shared not
one compiled dependency: every leg paid for the whole graph twice, in
series.
Split the addon into its own `build-rust-napi` matrix over the same eight
targets. Measured on the 12.0.0-rc.9 release run, per-leg build time was:
target CLI addon leg
win32-arm64 508s 369s 17m09s
win32-x64 495s 363s 15m06s
darwin-arm64 477s 241s 12m30s
darwin-x64 461s 235s 12m10s
linux-* 322-351s 217-238s ~10m
The stage is bounded by its slowest leg, so dropping the addon out of
win32-arm64 takes the critical path from ~17 to ~11 minutes and the whole
release run from ~25m30s to roughly 19 minutes. The addon legs run
alongside and gate nothing.
Downstream needs no changes: the new job uploads to
`binaries-rust-napi-<code-target>`, which the `binaries-rust-*` download
pattern the verify, publish and draft-release jobs already use picks up
and merges into the same directory. It is also free of the node-gyp
payload dependency, since only the CLI archives ship `dist/`.
The toolchain prelude the two jobs share — installing cross, the
clang-cl/ARM64 Visual Studio components, the rustup target, and the guard
that the committed PNPM_VERSION matches the tag — moves into a
`rust-release-target` composite action rather than being duplicated.
zizmor flags that action's writes to GITHUB_ENV/GITHUB_PATH because a
composite action cannot see who calls it; the values come from the
Visual Studio install and `vcvarsall`, and the only caller is a release
job running on a maintainer-signed tag, so the audit is suppressed on
that step with that justification.
* chore: update dependencies, Node.js, pnpm, and GitHub Actions
* chore: hold typescript on 6.x for typescript-eslint compatibility
The update-lockfile job bumped the `typescript` catalog entry to 7.0.2,
which typescript-eslint refuses to load against — it hard-errors at load
with "typescript-eslint does not support TS 7.0" — failing the
Compile & Lint job.
The 7.x compiler is already used for the build via
`@typescript/native-preview` (tsgo); the `typescript` npm package only
serves the JS-API tooling (eslint, jest), which needs 6.x until
typescript-eslint adds TS >=7.1 support
(https://github.com/typescript-eslint/typescript-eslint/issues/10940).
Revert the catalog entry to 6.0.3 and add `typescript` to
`update.ignoreDeps` so the update-lockfile workflow stops re-bumping it.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* chore: drop the stray typescript@7.0.2 from the lockfile
openpgp declares an optional `typescript` peer (>=4.7). After the catalog
was reverted to 6.0.3, pnpm's incremental resolution kept openpgp latched
onto the leftover typescript@7.0.2 node, leaving it (and its native
platform packages) in the lockfile and tripping peer-mismatch review bots.
Re-point openpgp's optional peer to 6.0.3 so typescript@7.0.2 is gone
entirely; the openpgp subtree is now identical to the base branch.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
