turborepo

Description Fixes the fixture cleanup race behind this JS test failure. and both use the fixture group. Their fixture directories have unique names, but each suite's deletes the shared parent. One suite can delete another suite's files during fixture copying, causing . Give each invocation its own parent directory: Add a deterministic regression test with real Jest hooks for named and unnamed fixture groups. Testing Instructions Manually reproduced the collision with the actual fixture helper: finishing one suite deleted another suite's active fixture, and failed with . With a per-suite parent, the active fixture survived the same teardown. Also confirmed that the new regression fails before the fix and passes afterward.

Description pnpm 10.8 and later read from ahead of , and pnpm 11 reads it only from (its changelog: " is auth/registry only"). turbo decided whether a repository uses per-workspace lockfiles only from . A repository that sets in was therefore treated as using a shared lockfile: every workspace's is empty, with a "Workspace not found in lockfile" warning; a lockfile-only bump in a workspace gives a stale cache hit when don't include that lockfile; leaves the workspace lockfiles out of , and the install there fails with . On pnpm 11 and 12, is the only place this setting can live, so this affects every repository using per-workspace lockfiles on current pnpm. Repro in , , a lockfile-only bump in (ms 2.1.2 → 2.1.3), then : Fix reads the setting from first, then , and defaults to shared, the same order turbo already uses for . The lockfile reader and prune both call it, so they can't disagree. The yaml value is read untyped, so an unexpected value can't fail parsing of the whole file (workspace globs, catalogs). covers every pnpm from 9 on, so turbo also reads the yaml key on pnpm 9 and 10.0–10.7, which ignore it. On pnpm 9.15.9 with the key in , hashes and output are identical to , and the pruned output installs frozen. Testing Instructions : (precedence per pnpm version), , and (lockfiles written by pnpm). : , the existing per-workspace fixture with the setting moved to . Tested on macOS (Apple Silicon) only; Linux and Windows not tested.

Description Yarn applies a dependency from a package extension only when the package doesn't already declare that dependency. Berry pruning didn't apply that rule, which breaks pruned output in two ways: Built-in extension. Prune kept whenever any was reachable, even when every reachable parser declares itself. Yarn drops that entry, so in fails with YN0028 ("The lockfile would have been modified"). Project . Prune kept every extension dependency for every matching package, with the same YN0028 result. When every matching package already declares the dependency (an extension that a package fixed upstream; Yarn warns YN0069), Yarn never resolves the extension's range, and the prune fails with . That hard error started in 2.10.6 (#13425). Repro The new fixture (written by Yarn 4.13.0): On hyperdx (Yarn 4.13.0), 2 of 6 prune targets install with on and 6 of 6 with this PR, including . Fix checks whether a package already lists a dependency. The two places that decide which extension dependencies to keep now use it: The built-in is kept only when a reachable doesn't declare . A project extension dependency is kept only when some reachable package matching the selector doesn't declare it. Not covered here: an extension whose range is rewritten by root or a entry still fails with , as on , because turbo looks the extension range up without applying the resolution. Skipping that error would silently drop a dependency that Yarn installs, so it needs its own fix. Testing Instructions : and , both on lockfiles trimmed from Yarn 4.13.0 output. With always returning false, both fail. : the fixture fails 3 of 6 targets on and passes 6 of 6 here. Tested on macOS (Apple Silicon) only; Linux and Windows not tested.