Repository navigation
ci: Empty cached node_modules that have broken .bin scripts - #25635
Merged
Merged
Conversation
All PR jobs share one Namespace cache volume for their node_modules folders. When the volume holds an isolated layout (from #25368) and a hoisted branch installs on top of it, pnpm 12 removes `node_modules/.pnpm`. It keeps the `.bin` scripts of the workspace packages, though, and they still run targets in `.pnpm`. Build then fails in `@sentry/angular` (`ng`) and `@sentry/nextjs` (`rollup`) with `Cannot find module '.../node_modules/.pnpm/...'`. Neither a second `pnpm install` nor `--force` removes these scripts, and every PR job that passes saves them back to the volume. So re-runs do not help. Before `pnpm install`, `install-dependencies` now empties the mounted node_modules folders when the layout on the volume differs from `nodeLinker`, or when a `.bin` entry points to a file that does not exist. The second check also repairs the volume that is broken now, and pnpm can leave such dead links after normal dependency changes too. The folders are mounted from the volume, so the step empties them instead of removing them. Removing only the broken links is not enough. pnpm does not recreate a missing link when the lockfile is up to date, so a package that needs its own version of a tool would silently run the root version instead. A full install takes about 30 seconds with a warm pnpm store. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Contributor
size-limit report 📦Compared: 873584a (PR test merge using develop at b3e0c9e) Against: b3e0c9e (develop) · base run #63030 ✅ Baseline matches: this diff contains only this PR's changes.
|
Contributor
Optional E2E testsSome optional checks were not successful. They do not block the merge. 1 failing, 63 successful. See the run.
Successful checks
|
JPeer264
approved these changes
Oct 22, 2026
JPeer264
left a comment
JPeer264
left a comment
Member
There was a problem hiding this comment.
Let's try that. I was already seeing that some binaries are getting downloaded. Didn't think it could have been something with the linker
51 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
All PR jobs share one Namespace cache volume for their node_modules folders. When the volume holds an isolated layout (from #25368) and a hoisted branch installs on top of it, pnpm 12 removes
node_modules/.pnpm. It keeps the.binscripts of the workspace packages, though, and they still run targets in.pnpm. Build then fails in@sentry/angular(ng) and@sentry/nextjs(rollup) withCannot find module '.../node_modules/.pnpm/...'. Neither a secondpnpm installnor--forceremoves these scripts, and every PR job that passes saves them back to the volume. So re-runs do not help.Before
pnpm install,install-dependenciesnow empties the mounted node_modules folders when the layout on the volume differs fromnodeLinker, or when a.binentry points to a file that does not exist. The second check also repairs the volume that is broken now, and pnpm can leave such dead links after normal dependency changes too. The folders are mounted from the volume, so the step empties them instead of removing them.Removing only the broken links is not enough. pnpm does not recreate a missing link when the lockfile is up to date, so a package that needs its own version of a tool would silently run the root version instead. A full install takes about 30 seconds with a warm pnpm store.