turborepo

Description Running any pnpm command in this repo with pnpm 11 prints: pnpm 11 dropped support for reading settings out of the field in . The launcher emits this warning before it delegates to the version pinned in (pnpm 10.28.0), so the warning shows up on every command even though the override is still being applied by the delegated pnpm 10. This moves the lone setting we had there — the override — to the top-level key in , which is the documented home for it. already holds our other pnpm settings (, ), and pnpm 10.28.0 reads from there, so the pinned version keeps working unchanged. is untouched: it already records , and it still resolves to exactly that after the move. The entries under and the other directories are deliberately left alone — those fixtures pin older pnpm versions and exist to exercise the lockfile parsers against that format. Testing Instructions With pnpm 11 installed: The lockfile is unaffected: And the override is still in effect: I also sanity-checked that the setting is actually being read from the new location by temporarily changing it to and confirming the lockfile's block and resolved versions followed, then reverting.

Summary Remediates GHSA-5p4m-2wfm-xmqj / CVE-2026-59870 (High, CWE-407) — quadratic CPU consumption in js-yaml's resolution. enforces key uniqueness with a linear scan inside the per-element loop, making resolution O(n²) in the number of entries. is registered in the default schema, so a plain with no options is affected — the work happens synchronously and blocks the event loop for its whole duration. Scope: three packages, not one The report flagged (4.3.0), but the advisory range is , so the two pins are vulnerable to the same issue. All three call with the default schema: matters in particular: it is consumed by and several other packages, so fixing only the reported pin would have left the same vulnerable code reachable. 4.3.1 replaces the linear scan with an O(1) key lookup. Staying on the 4.x line keeps this a patch-level bump with no API change. Verification Advisory PoC — load time now scales linearly instead of quadratically: Correctness preserved: duplicate keys are still rejected (), and valid omaps parse as before. Tests — captured a baseline on unmodified , then re-ran after the bump. Suite and test counts are byte-identical across every changed package and every consumer of : — 986 passed — 89 passed — 74 passed , , , — unchanged from baseline The pre-existing failures in those last four are sandbox artifacts ( — the task and was not built here). They fail identically before and after this change. succeeds, confirming the lockfile matches the manifests. The lockfile also deduped , , and onto 4.3.1, since those carry ranges. Left out, deliberately The docs site still resolves js-yaml 4.2.0 transitively through and , which pin the version exactly. Forcing those would require a entry pushing a version upstream has not tested against, and those packages parse only repo-owned MDX at build time — there is no untrusted-input path. Happy to add the override if you would rather have a clean . 🤖 Generated with Claude Code

Why copies each retained package with a walk anchored at the repository root. That anchoring is deliberate — it is what makes the ignore files above a package apply to it (#12953) — but it is paid once per package. Every copy re-reads each directory on the way down from the root and recompiles every ancestor ignore file, so the cost grows with . In a large monorepo, pruning one service copies ~440 packages, and each of those copies re-lists the same two top-level workspace directories (748 and 387 entries) and recompiles the root . That overhead is ~85% of the command's runtime: the same prune with (identical output, since the ignored paths are not in these packages) took 0.94s versus 3.9s. What Resolve the contents of every package directory in a single walk of the repository, and hand each copy the entries that belong to it. gains , which walks one root for many sources and records each source's entries. is now a plan with nothing precomputed, so the single-source path is unchanged. builds the plan once from the package closure it is about to copy. The plan is also reused when the same directory is copied to more than one destination. Anything the plan does not cover — dependency directories, the additional directories, — walks on demand exactly as before. Ignore semantics are untouched: it is the same walker, rooted at the same directory, with the same options. Only the set of directories it is allowed to descend into is wider, and each entry is attributed to the sources that contain it. Results Measured on two large private monorepos, referred to here as A and B — actively developed repositories rather than synthetic fixtures. To give a sense of their size without identifying them: A is the higher-fan-out of the two, its two top-level workspace directories listing 748 and 387 entries between them, with the service scope below retaining ~440 packages. B retains fewer packages per scope but carries more content in each: its largest measured scope retains 84 packages and produces 26,436 entries, against 10,157 for the largest A scope. The timings are whole-repository runs at that scale, not micro-benchmarks. Median of 7 alternating runs, hot page cache, 4 vCPU: The win scales with how many packages a scope retains, which is why repository A gains the most. is unchanged (0.534s → 0.542s, noise), as expected: that path never shared a walk root. Verification Output equivalence on both repositories: for each scope, the full pruned tree (26,436 entries for the largest B scope, 10,157 for the largest A scope) was compared entry by entry — path, SHA-256, mode, and symlink target — against the tree produced by the current binary. Everything matches. One caveat worth reporting separately: in one of the two repositories, already writes nondeterministically (two runs of the same binary differ in key order). That file was the only difference between runs, and it differs between two baseline runs as well, so it is pre-existing and not from this change. New unit tests in assert that a planned copy is identical to an individual for the same source, that ignore files above the package still apply (including a root-anchored pattern that must not leak into a sibling package, and a nearer negation that must win), that unplanned sources fall back correctly, and that a package nested inside another package lands in both copies. , , on both changed crates, and all pass. is 25/26; fails identically on unmodified in this environment (its step), so it is not related to this change. 🤖 Generated with Claude Code