fix: downgrade ERR_PNPM_IGNORED_BUILDS to a warning#7527
Merged
JohnMcLear merged 1 commit intodevelopfrom Apr 16, 2026
Merged
Conversation
Plugin CI is still failing on ERR_PNPM_IGNORED_BUILDS even with the build-script policy declared in both pnpm-workspace.yaml (#7523) and package.json (#7525). pnpm's strict-dep-builds defaults to true in 10+, so any transitive dep with an unrecognized postinstall fails the build. For etherpad-lite — and especially for downstream plugin repos that pull this codebase as their core install — that's a footgun: the moment some new transitive ships a postinstall, every plugin's CI explodes. Set strictDepBuilds: false in pnpm-workspace.yaml AND strict-dep-builds=false in .npmrc as a defensive layer, so unknown postinstalls become a warning instead of a hard failure. The allow/ignore lists still control what actually runs. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Review Summary by QodoDowngrade ERR_PNPM_IGNORED_BUILDS to warning via pnpm config
WalkthroughsDescription• Downgrade pnpm strict-dep-builds errors to warnings • Add .npmrc configuration with strict-dep-builds=false • Add strictDepBuilds: false to pnpm-workspace.yaml • Prevent CI failures from unknown transitive dependency postinstall scripts Diagramflowchart LR
A["Unknown postinstall scripts"] -->|Previously| B["ERR_PNPM_IGNORED_BUILDS failure"]
A -->|Now| C["Warning only"]
D[".npmrc: strict-dep-builds=false"] --> C
E["pnpm-workspace.yaml: strictDepBuilds: false"] --> C
C --> F["CI continues successfully"]
File Changes1. .npmrc
|
Code Review by Qodo
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
Comment on lines
+14
to
+17
| # Belt-and-suspenders: even if a fresh transitive dep slips through with a | ||
| # postinstall script, downgrade to a warning so CI doesn't break for | ||
| # downstream plugin repos that pull etherpad-lite as their core install. | ||
| strictDepBuilds: false |
There was a problem hiding this comment.
1. No regression test for pnpm config 📘 Rule violation ☼ Reliability
This bug fix changes install behavior by disabling strict dependency builds, but the PR adds no regression test to ensure ERR_PNPM_IGNORED_BUILDS remains downgraded to a warning in future changes. Without a test, the strict mode could be re-enabled inadvertently and CI failures would regress.
Agent Prompt
## Issue description
The PR changes pnpm install behavior by disabling strict dependency builds, but does not add a regression test that would fail if strict mode is re-enabled.
## Issue Context
The goal is to prevent future regressions where `ERR_PNPM_IGNORED_BUILDS` starts failing CI again. A regression test could validate that the repo’s install configuration keeps strict-dep-builds disabled (or that an install with a fixture postinstall does not fail).
## Fix Focus Areas
- .npmrc[1-1]
- pnpm-workspace.yaml[14-17]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| @@ -0,0 +1 @@ | |||
| strict-dep-builds=false | |||
There was a problem hiding this comment.
2. Docker skips pnpm setting 🐞 Bug ☼ Reliability
The PR adds strict-dep-builds=false in .npmrc, but the Docker production build stage never copies .npmrc into the image and also overwrites pnpm-workspace.yaml, so the `pnpm --recursive i invoked by bin/installDeps.sh` during the production image build will not see this new configuration.
Agent Prompt
## Issue description
The PR’s new pnpm config (`strict-dep-builds=false`) is stored in `.npmrc`, but the Docker production image build path does not include `.npmrc` in the image filesystem, so `pnpm` runs during `bin/installDeps.sh` won’t see the new setting.
## Issue Context
- Docker `production` target is used in CI (`.github/workflows/docker.yml`).
- The Docker `build` stage copies a small subset of files and currently omits `.npmrc`.
- The Docker `production` stage overwrites `pnpm-workspace.yaml`, which also removes the PR’s `strictDepBuilds: false` workspace fallback.
## Fix Focus Areas
- Dockerfile[121-126]
- Dockerfile[174-178]
## Suggested change
1) Update the selective `COPY` in the `build` stage to include `./.npmrc` so downstream stages inherit it.
2) (Optional belt-and-suspenders) When overwriting `pnpm-workspace.yaml` for production, include `strictDepBuilds: false` in the generated YAML as well, so the production target remains protected even if `.npmrc` handling changes later.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
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
1 participant
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.
Summary
Plugin CI is still failing on `ERR_PNPM_IGNORED_BUILDS` even with the build-script allowlist declared in both `pnpm-workspace.yaml` (#7523) and `package.json` (#7525) — every downstream plugin repo's backend tests now fail when running `bin/installDeps.sh` against `develop`.
The root cause: pnpm's `strict-dep-builds` defaults to `true` in 10.x, so any transitive dep with an unrecognized postinstall fails the install. That makes any new transitive landing in `pnpm-lock.yaml` a footgun for every plugin repo's CI.
Fix
Set the strict-mode setting to `false` in two places:
Unknown postinstalls now emit a warning instead of failing. The existing `onlyBuiltDependencies` (esbuild) and `ignoredBuiltDependencies` (@scarf/scarf) lists still control what actually runs.
Verified locally that a fresh `pnpm install` (with store pruned) still:
Generated with Claude Code