• Shard Windows TypeScript CI tests into three parallel chunks on Node 22 only.
• Add a helper to shard Jest files per workspace package and run them consistently.
• Preserve Bencher artifacts with chunk-specific benchmark and artifact naming.

graph TD
  A[".github/workflows/ci.yml (matrix)"] --> B[".github/workflows/test.yml (reusable)"] --> C{"chunking enabled?"}
  C -->|"total=1"| D["pn run ci:test-* (pnpm)"] --> H[("Bencher JSON + artifact")]
  C -->|"total>1"| E["run-ts-tests-chunk.mjs"] --> F["pnpm list + discover Jest files"] --> G["pnpm exec jest --runTestsByPath"] --> I[("pnpm-exec-summary.json")]
  I --> H
  subgraph Legend
    direction LR
    _wf["Workflow/Step"] ~~~ _dec{"Decision"} ~~~ _art[("Artifact/File")]
  end

Loading

The following are alternative approaches to this PR:

1. Use Jest built-in sharding (--shard)

• ➕ Eliminates custom file discovery and greedy balancing logic
• ➕ Leverages a standardized, well-tested sharding mechanism
• ➖ Hard to apply cleanly across a pnpm monorepo with per-package pretest/setup
• ➖ Does not naturally preserve pnpm-style per-package execution summaries used by existing Bencher extraction

2. Shard by workspace package (not by test file)

• ➕ Much simpler implementation (split package list into N buckets)
• ➕ Stable chunk membership even when files move within a package
• ➖ Likely poor load balancing because package test sizes vary widely
• ➖ Still needs special handling for non-Jest .test scripts and pretest hooks

3. GitHub Actions dynamic matrix from discovered tests

• ➕ Moves sharding to workflow level; clearer CI visibility per shard
• ➕ Potentially easier artifact isolation per shard
• ➖ Complex to generate/consume dynamic matrices reliably across runners
• ➖ Still requires custom discovery logic; more moving parts than the current approach

Recommendation: Keep the PR’s approach: a single helper that shards Jest files while preserving per-package setup and pnpm execution summaries. This best matches the monorepo constraints (pretest hooks, mixed test scripts, and existing Bencher tooling) while delivering predictable wall-clock improvements on Windows via 3-way parallelism.

Other (3) +414 / -24

run-ts-tests-chunk.mjsAdd CI helper to shard TS Jest tests into balanced chunks +333/-0

Add CI helper to shard TS Jest tests into balanced chunks

• Introduces a Node script that selects workspace packages (full vs affected), enumerates Jest test files, greedily balances them into N chunks by file size, and runs selected files via per-package Jest invocations. Preserves package pretest behavior, injects required NODE_OPTIONS, and writes a pnpm-style execution summary for downstream Bencher duration extraction.

.github/scripts/run-ts-tests-chunk.mjs

ci.ymlShard Windows TS test matrix and limit Windows runs to Node 22 +26/-14

Shard Windows TS test matrix and limit Windows runs to Node 22

• Extends the TS CI change filter to include .github/scripts, ensuring CI changes trigger the workflow. Replaces the previous multi-node Windows matrix with three Windows chunk entries (1/3, 2/3, 3/3) on Node 22, while keeping Ubuntu coverage across Node 22 and 26, and wires chunk inputs into the reusable test workflow.

.github/workflows/ci.yml

test.ymlAdd chunk inputs and chunk-aware concurrency/Bencher artifacts to reusable test workflow +55/-10

Add chunk inputs and chunk-aware concurrency/Bencher artifacts to reusable test workflow

• Adds workflow_call inputs for chunk index/total and includes them in the job name and concurrency group to avoid cross-chunk cancellation. Runs either the existing pnpm test script or the new sharding helper, and updates Bencher benchmark names, merged result inputs, metadata, and artifact names to be chunk-specific while staying under the existing testbed naming scheme.

.github/workflows/test.yml

Walkthrough

Adds a new Node.js script that discovers Jest packages in the pnpm monorepo, enumerates test files with size-based weights, selects a greedy-balanced chunk, and executes Jest per package. Updates ci.yml to use an explicit matrix with chunk parameters and test.yml to conditionally invoke the chunk runner and produce chunk-aware Bencher benchmark names and artifacts. Extends Bencher result parsing to support --allow-missing flag.

Changes

Chunked TypeScript test execution

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

• pnpm/pnpm#12388: Introduces .test:heavy script suffix on specific test files; the chunk runner detects isolated test file patterns from .test:* scripts for separate batch execution.
• pnpm/pnpm#12404: The chunk runner generates pnpm-exec-summary.json with per-package duration and status; the related PR modifies bencher-result-from-pnpm-summary.mjs which consumes this output.
• pnpm/pnpm#12544: Both modify the Bencher extraction and merge steps in test.yml; this PR adds chunk-aware benchmark naming and conditional CLI duration extraction with --allow-missing support.

• X
• Mastodon
• Reddit
• LinkedIn

Description

runJestPackage() prepends workspace node_modules/.bin directories to PATH and then invokes
runPnpm(), which spawns the bare command pn; this allows a pn executable placed in those
.bin dirs to hijack the runner and potentially skip/fake test execution or summaries. This is a CI
integrity/security issue introduced by the new chunk runner’s environment setup and command spawning
behavior.

Code

.github/scripts/run-ts-tests-chunk.mjs[R119-143]

+  const env = {
+    ...process.env,
+    NODE_OPTIONS: withJestNodeOptions(process.env.NODE_OPTIONS),
+    PNPM_SCRIPT_SRC_DIR: pkg.path,
+  }
+  prependPath(env, [
+    path.join(pkg.path, 'node_modules', '.bin'),
+    path.join(rootDir, 'node_modules', '.bin'),
+  ])
+  if (pkg.manifest.name === '@pnpm/installing.deps-installer') {
+    env.PNPM_REGISTRY_MOCK_PORT = '7769'
+  }
+
+  let status = 'passed'
+  let exitCode = 0
+  try {
+    if (pkg.manifest.scripts.pretest != null) {
+      await runPnpm(['--dir', pkg.path, 'run', 'pretest'], { env })
+    }
+    for (const [index, files] of batches.entries()) {
+      if (batches.length > 1) {
+        console.log(`Running batch ${index + 1}/${batches.length} (${files.length} Jest file(s)) in ${relDir}`)
+      }
+      await runPnpm(['--dir', pkg.path, 'exec', 'jest', '--runTestsByPath', ...files], { env })
+    }

Evidence

The script explicitly prepends pkg.path/node_modules/.bin and rootDir/node_modules/.bin to PATH,
then runs runPnpm() using that environment; runPnpm() ultimately spawns the bare command pn
(resolved via PATH), enabling executable shadowing/hijack via those prepended directories.

.github/scripts/run-ts-tests-chunk.mjs[112-143]
.github/scripts/run-ts-tests-chunk.mjs[284-311]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The chunk runner prepends `node_modules/.bin` to `PATH` and then executes `pn` by name. Because `spawn()` resolves bare commands via `PATH`, any `pn` binary/shim in those prepended directories can be executed instead of the intended pnpm runner.
### Issue Context
This happens inside `runJestPackage()` when preparing the environment for Jest runs, and affects all subsequent `runPnpm()` calls made with that `env`.
### Fix Focus Areas
- Ensure `runPnpm()`/`capturePnpm()` invoke a trusted `pn` executable (prefer an absolute path resolved once at startup, e.g. from `PNPM_HOME`, or a pre-resolved `which/where pn` result) so later PATH edits cannot change which binary runs.
- Alternatively, avoid prepending `.bin` to PATH entirely (pnpm `exec` already resolves package bins), or append instead of prepend so toolchain resolution stays stable.
- .github/scripts/run-ts-tests-chunk.mjs[112-143]
- .github/scripts/run-ts-tests-chunk.mjs[284-309]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

run-ts-tests-chunk.mjs runs one Jest invocation per package with --runTestsByPath, bypassing
package .test script sequencing. For @pnpm/installing.deps-installer, this can place
test/install/deepRecursive.ts in the same Jest process as other tests when they land in the same
chunk, undermining the repo’s existing heavy/rest split and increasing the chance of Windows CI
timeouts/flakes.

Code

.github/scripts/run-ts-tests-chunk.mjs[R133-136]

+    if (pkg.manifest.scripts.pretest != null) {
+      await runPnpm(['--dir', pkg.path, 'run', 'pretest'], { env })
+    }
+    await runPnpm(['--dir', pkg.path, 'exec', 'jest', '--runTestsByPath', ...relFiles], { env })

Evidence

The new runner always calls pn ... exec jest --runTestsByPath ...relFiles, so it does not honor
per-package .test script logic. The deps-installer package.json demonstrates the repo previously
isolated deepRecursive.ts into a separate test phase (.test:heavy) before running the rest,
which the new runner can defeat when a chunk includes both heavy and non-heavy files for that
package.

.github/scripts/run-ts-tests-chunk.mjs[111-137]
pnpm11/installing/deps-installer/package.json[49-58]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The chunk runner executes Jest directly with `--runTestsByPath` over all selected files for a package, which bypasses packages’ `.test` orchestration. `@pnpm/installing.deps-installer` explicitly splits its suite into a heavy test (`deepRecursive.ts`) and the rest; the current sharding runner can recombine those into one Jest process whenever the chunk selects both.
### Issue Context
- `@pnpm/installing.deps-installer`’s `.test` script runs `.test:heavy` (only `test/install/deepRecursive.ts`) and then `.test:rest` (everything else).
- The sharded runner currently runs `jest --runTestsByPath ...relFiles` once per package, so a chunk that includes `deepRecursive.ts` and other files will execute them together.
### Fix Focus Areas
- .github/scripts/run-ts-tests-chunk.mjs[111-147]
- pnpm11/installing/deps-installer/package.json[49-59]
### Suggested fix approach
In `runJestPackage`, add a small package-specific preservation of the existing split:
- If `pkg.manifest.name === '@pnpm/installing.deps-installer'` and the selected `relFiles` contains `test/install/deepRecursive.ts` *and* at least one other file, run two Jest commands:
1) `jest --runTestsByPath test/install/deepRecursive.ts`
2) `jest --runTestsByPath <all remaining files>`
- Keep the existing `pretest` handling and `PNPM_REGISTRY_MOCK_PORT` env.
- Ensure failures from either invocation are reflected in `executionStatus[pkg.path]` (current outer timing can remain as-is).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

run-ts-tests-chunk.mjs only records executionStatus entries for packages that actually run in
the selected chunk, so a chunk can omit pnpm11/pnpm entirely. When full_tests == true,
test.yml always runs bencher-result-from-pnpm-summary.mjs --package-dir pnpm11/pnpm, which exits
non-zero if that summary entry is missing, failing the job.

Code

.github/scripts/run-ts-tests-chunk.mjs[R24-34]

+if (!dryRun) {
+  for (const pkg of packages) {
+    const selectedPackage = selectedPackages.get(pkg.path)
+    if (selectedPackage != null) {
+      await runJestPackage(pkg, selectedPackage)
+    } else if (selectedTasks.some((task) => task.kind === 'script' && task.packagePath === pkg.path)) {
+      await runScriptTask(pkg)
+    }
+  }
+  await writeSummary(summary, executionStatus)
+}

Evidence

The chunk runner only runs packages that have tasks selected for that chunk and only then inserts an
executionStatus entry; the Bencher extractor requires an entry for pnpm11/pnpm and exits 1 if it
is missing, while the workflow runs this extractor on full test runs regardless of whether the chunk
executed that package.

.github/scripts/run-ts-tests-chunk.mjs[16-34]
.github/scripts/run-ts-tests-chunk.mjs[52-109]
.github/scripts/run-ts-tests-chunk.mjs[111-143]
.github/scripts/bencher-result-from-pnpm-summary.mjs[6-20]
.github/workflows/test.yml[177-217]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The chunked TS test runner writes `pnpm-exec-summary.json` with `executionStatus` entries only for packages executed in that chunk. The workflow later always tries to extract a Bencher result for `pnpm11/pnpm` from that summary on full test runs; if a chunk contains no `pnpm11/pnpm` tasks, the summary omits that key and the extraction step fails.
### Issue Context
- `run-ts-tests-chunk.mjs` iterates all packages but only executes packages present in `selectedPackages` (jest files) or a selected `script` task, and only then writes `executionStatus[pkg.path]`.
- `bencher-result-from-pnpm-summary.mjs` hard-fails if the entry for `resolve('pnpm11/pnpm')` is missing.
- `test.yml` always runs the CLI-duration extraction step when `full_tests == true`, including chunked runs.
### Fix Focus Areas
Choose one of these approaches (A is minimal and safest):
A) **Make CLI-duration extraction non-fatal/optional when chunked**
- Add a flag to `bencher-result-from-pnpm-summary.mjs` like `--optional` (or `--allow-missing`) that exits 0 without writing output when the summary entry is missing (or not `passed`).
- In `.github/workflows/test.yml`, pass that flag when `TEST_CHUNK_TOTAL != 1` (or gate the step similarly), relying on the later merge step which already conditionally includes the CLI benchmark file only if it exists.
B) **Guarantee `pnpm11/pnpm` appears in every chunk**
- Adjust task selection to pre-seed each chunk with at least one Jest file from `pnpm11/pnpm` (or otherwise enforce presence), so the package is always executed and a summary entry is always produced.
- .github/scripts/run-ts-tests-chunk.mjs[16-34]
- .github/scripts/bencher-result-from-pnpm-summary.mjs[6-20]
- .github/workflows/test.yml[177-217]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The new build-pnpr job is a single Linux+Windows matrix and is listed in needs for both Ubuntu
and Windows test jobs, which forces Ubuntu tests to wait for the Windows pnpr build even though they
only consume the Linux artifact. This increases CI wall-clock time and makes a Windows-only pnpr
build failure prevent Linux tests from running, reducing feedback signal.

Code

.github/workflows/ci.yml[R77-89]

+  # Build the pnpr server and registry fixture preparer once per OS, then
+  # share the binaries with every test job/shard as an artifact. Building
+  # inside each test job instead rebuilt pnpr once per shard, because the
+  # parallel shards all miss the build cache at job start.
+  build-pnpr:
+    needs: changes
+    if: ${{ !cancelled() && needs.changes.outputs.ts == 'true' && (github.event_name == 'push' || github.event.pull_request.head.repo.full_name != github.repository || github.head_ref == 'chore/update-lockfile') }}
+    name: TS CI / Build pnpr / ${{ matrix.os }}
+    strategy:
+      fail-fast: false
+      matrix:
+        os: [ubuntu-latest, windows-latest]
+    runs-on: ${{ matrix.os }}

Evidence

build-pnpr is defined as a two-OS matrix job, while test-smoke and test-windows both declare
needs: [compile-and-lint, build-pnpr]. Since needs waits on the aggregate matrix result, Ubuntu
tests are gated on the Windows pnpr build completing successfully.

.github/workflows/ci.yml[77-89]
.github/workflows/ci.yml[145-219]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`build-pnpr` is implemented as a single matrix job over `ubuntu-latest` and `windows-latest`, and downstream jobs depend on the whole matrix via `needs: build-pnpr`. In GitHub Actions, that means downstream jobs wait for *all* matrix children to complete, so Ubuntu tests are unnecessarily blocked on the Windows pnpr build.
### Issue Context
The tests download OS-specific artifacts (`pnpr-bins-${{ runner.os }}`) and do not need the other OS’s artifact.
### Fix Focus Areas
- .github/workflows/ci.yml[77-219]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

When --allow-missing is set, bencher-result-from-pnpm-summary.mjs exits 0 without emitting any
warning or writing an output JSON, so a missing CLI-duration entry is silently ignored and benchmark
completeness issues are hard to detect.

Code

.github/scripts/bencher-result-from-pnpm-summary.mjs[R14-16]

+  if (allowMissing) {
+    process.exit(0)
+  }

Evidence

The script exits successfully on missing entries when --allow-missing is set, and the workflow
later conditionally merges the CLI benchmark file only if it exists; together this makes missing
CLI-duration benchmark data silently disappear.

.github/scripts/bencher-result-from-pnpm-summary.mjs[12-18]
.github/workflows/test.yml[253-256]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`--allow-missing` currently causes an early `process.exit(0)` with no log and no output file. In the shard workflow, the CLI benchmark file is optional, so this becomes a silent drop of benchmark telemetry when the summary entry is unexpectedly absent.
### Issue Context
This behavior is intentional to avoid failing shards that don’t run `pnpm11/pnpm`, but it still needs a signal when it happens so missing benchmark data doesn’t go unnoticed.
### Fix Focus Areas
- .github/scripts/bencher-result-from-pnpm-summary.mjs[12-19]
### Suggested change
In the `allowMissing` branch, emit a GitHub Actions warning (and/or a stderr warning) including `packagePath` and `summaryPath` before exiting, e.g.:
- `console.log('::warning::...')` then `process.exit(0)`.
This preserves shard success while making missing benchmark output discoverable in logs.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The new build-pnpr cache key only hashes Rust manifests and *.rs files, but the pnpr binaries embed
non-Rust assets (e.g. config.yaml and the repo LICENSE) via include_str!. As a result, CI can
restore and run stale pnpr binaries after those assets change, masking behavior changes and
producing incorrect test coverage/results.

Code

.github/workflows/ci.yml[R105-111]

+    - name: Restore prebuilt pnpr binaries
+      id: pnpr-bins
+      uses: actions/cache/restore@27d5ce7f107fe9357f9df03efb73ab90386fccae # v5.0.5
+      with:
+        path: .pnpr-bin
+        key: pnpr-bins-${{ runner.os }}-${{ hashFiles('rust-toolchain.toml', '**/Cargo.lock', '**/Cargo.toml', 'pnpr/**/*.rs', 'pacquet/**/*.rs') }}
+    - name: Install Rust

Evidence

The workflow cache key hashes only Rust sources/manifests, but pnpr and pnpr-fixtures compile in
non-Rust files using include_str!, so changes to those files won’t invalidate the cache and can lead
to stale restored binaries.

.github/workflows/ci.yml[105-111]
pnpr/crates/pnpr/src/config.rs[19-26]
pnpr/crates/pnpr-fixtures/src/lib.rs[273-292]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`build-pnpr` caches `.pnpr-bin` using a key that ignores non-Rust files that are compiled into the pnpr binaries via `include_str!`. This can restore stale binaries when those embedded assets change.
### Issue Context
The cache key currently hashes `rust-toolchain.toml`, all `Cargo.*`, and `pnpr/**/*.rs` + `pacquet/**/*.rs`, but pnpr and pnpr-fixtures embed non-`.rs` files into the binaries.
### Fix Focus Areas
- .github/workflows/ci.yml[105-111]
### What to change
- Expand the `hashFiles(...)` key inputs to include embedded assets that affect the compiled output, at minimum:
- `pnpr/crates/pnpr/config.yaml`
- `LICENSE`
- Optionally, also include any other non-Rust files referenced by `include_str!` / `include_bytes!` in the built crates (keep it scoped to avoid hashing large fixture trees).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools