Found while measuring #282's mechanism assumptions (session session_01FeA1nwBz1ohH65dvffUGKr). Observation only; nothing here is changed by #282's PR.
What the patch header says
patches/fumadocs-core@16.8.12.patch, section "ON A VERSION BUMP": the pin "is pinned to 16.8.12 by the key in package.json, so any other version simply does not receive it and the defect returns silently". #282's card table repeats it ("the version moves: the pin simply does not match, no patch is applied, install succeeds").
What pnpm 10.28.2 actually does, measured
On a detached tree at cb0c146 with #239's one-line change (apps/docs/package.json: fumadocs-core 16.8.12 to 16.15.2):
| install |
exit |
what it printed |
pnpm install --frozen-lockfile (lockfile not yet updated) |
1 |
specifiers in the lockfile don't match |
pnpm install --no-frozen-lockfile |
1 |
ERR_PNPM_UNUSED_PATCH The following patches were not used: fumadocs-core@16.8.12 |
pnpm install --lockfile-only |
1 |
same ERR_PNPM_UNUSED_PATCH |
pin deleted from root package.json, then pnpm install --no-frozen-lockfile |
0 |
nothing; 16.15.2 installed unpatched |
lockfile regenerated with --config.allow-unused-patches=true (exit 0, one WARN), then pnpm install --frozen-lockfile |
0 |
nothing: the frozen install does not check for an unused patch |
So a bump is loud where the lockfile is regenerated, and the header's "silently" is wrong for that path. It is silent on two paths: deleting the pin, which is the first remedy pnpm's own error text offers ("Either remove them from patchedDependencies or update them"), and a lockfile produced with unused patches allowed, which CI's --frozen-lockfile then accepts. On the pin-deleted tree, a full build puts the defect back at 67 numeric character references and 4 of 661 malformed link targets in both llms consumers, and #282's gate reddens on it.
Why it matters beyond the comment
Suggested fix (not applied)
Correct the "ON A VERSION BUMP" paragraph of the patch header to say what is measured above. It sits under patches/, outside #282's file surface, so it is filed here rather than folded in.
Generated by Claude Code
Found while measuring #282's mechanism assumptions (session
session_01FeA1nwBz1ohH65dvffUGKr). Observation only; nothing here is changed by #282's PR.What the patch header says
patches/fumadocs-core@16.8.12.patch, section "ON A VERSION BUMP": the pin "is pinned to 16.8.12 by the key inpackage.json, so any other version simply does not receive it and the defect returns silently". #282's card table repeats it ("the version moves: the pin simply does not match, no patch is applied, install succeeds").What pnpm 10.28.2 actually does, measured
On a detached tree at
cb0c146with #239's one-line change (apps/docs/package.json:fumadocs-core16.8.12 to 16.15.2):pnpm install --frozen-lockfile(lockfile not yet updated)pnpm install --no-frozen-lockfileERR_PNPM_UNUSED_PATCH The following patches were not used: fumadocs-core@16.8.12pnpm install --lockfile-onlyERR_PNPM_UNUSED_PATCHpackage.json, thenpnpm install --no-frozen-lockfile--config.allow-unused-patches=true(exit 0, one WARN), thenpnpm install --frozen-lockfileSo a bump is loud where the lockfile is regenerated, and the header's "silently" is wrong for that path. It is silent on two paths: deleting the pin, which is the first remedy pnpm's own error text offers ("Either remove them from patchedDependencies or update them"), and a lockfile produced with unused patches allowed, which CI's
--frozen-lockfilethen accepts. On the pin-deleted tree, a full build puts the defect back at 67 numeric character references and 4 of 661 malformed link targets in bothllmsconsumers, and #282's gate reddens on it.Why it matters beyond the comment
Suggested fix (not applied)
Correct the "ON A VERSION BUMP" paragraph of the patch header to say what is measured above. It sits under
patches/, outside #282's file surface, so it is filed here rather than folded in.Generated by Claude Code