What the bug is and how it manifests

The repository explicitly enforces a supply-chain security policy via frontend/.npmrc: min-release-age=7. This setting, documented in root CLAUDE.md ("Both backend/ and frontend/ enforce a minimum release age of 7 days for npm packages... This means npm install will only resolve package versions published at least 7 days ago"), prevents npm from resolving packages published less than 7 days ago during dependency resolution.

dompurify 3.4.0 was published on 2026-04-14T07:51:39Z. This PR was opened 2026-04-16 — exactly 2 days later. The 7-day minimum-age window does not expire until 2026-04-21.

The specific code path that triggers it

Snyk runs in its own environment (likely without the local .npmrc policy), so it successfully resolves and pins dompurify 3.4.0 in package-lock.json. In the repo, any developer who regenerates the lockfile (deletes package-lock.json and runs npm install) before April 21 will trigger npm's dependency resolution phase, during which npm will see dompurify@^3.4.0 in package.json, attempt to resolve it, and the min-release-age=7 check will block 3.4.0 as it's only 2 days old.

Why existing code doesn't prevent it

The .npmrc policy is intentionally designed to protect against supply-chain attacks on newly published packages. However, Snyk's automated PR generation bypasses this check because Snyk runs in a sandboxed environment without the project's local .npmrc. The policy is enforced locally and in CI only when npm install (with resolution) is invoked — not when npm ci is used (which reads the lockfile directly, bypassing resolution entirely).

What the impact would be

The refutation correctly notes that npm install with an existing, compatible lockfile does not re-resolve dependencies, so ordinary developer npm install runs are unaffected. Similarly, npm ci (used in CI/CD pipelines) is unaffected. The failure scenario is narrowed to: a developer deletes package-lock.json (e.g., to resolve a merge conflict, add a new dependency from scratch, or troubleshoot) and runs npm install before April 21. During that ~5-day window, the install would fail with an error citing the min-release-age constraint. This is a real — if limited — developer friction point that directly contradicts the project's documented security policy.

How to fix it

The simplest fix is to delay merging this PR until 2026-04-21, when dompurify 3.4.0 will satisfy the 7-day constraint. Alternatively, if the security vulnerability is urgent enough to merge immediately, team members should be warned not to regenerate the lockfile until April 21.

Step-by-step proof

1. Confirm: frontend/.npmrc contains min-release-age=7
2. Confirm: dompurify 3.4.0 published 2026-04-14 (npm registry: "time": {"3.4.0": "2026-04-14T07:51:39.768Z"})
3. PR opened: 2026-04-16. Age of 3.4.0 at PR creation = 2 days < 7 days required
4. Developer action: rm frontend/package-lock.json && npm install (in frontend/)
5. npm resolves dompurify@^3.4.0 → finds 3.4.0 as latest matching version
6. npm checks min-release-age=7 → 3.4.0 is 2 days old → resolution blocked
7. Result: npm ERR! No matching version found for dompurify@^3.4.0 (or equivalent min-release-age error)
8. After 2026-04-21: same steps succeed normally — the issue is self-resolving