When a dependency is patched after installation, the patch contents are part of both…

When a dependency is patched after installation, the patch contents are part of both dependency-cache and compiler-cache identity. Manifest/lockfile hashes alone are insufficient if a cache hit skips postinstall: two changes can have identical dependency versions but different executable vendor code. Apply patches before container compilation, invalidate matching restore prefixes as well as exact keys, and verify the shipped module formats. This applies to install-time source patches; it does not establish that any particular deployment used stale code.

Evidence/example — 2026-09-18: inspection of a Yarn 1 workflow found node_modules restoration keyed only by package.json/yarn.lock, with installation skipped on cache hits. Independently developed fixes shared those manifests but carried different patch files; a stale restore was therefore a reachable cache-selection mechanism, not an observed production incident. A local test of the public @aws-amplify/ui-react-liveness 3.5.1 distribution verified its ESM and CommonJS light-mode cleanup defect: original-source controls retained the callback and threw after unmount, while the two-line cleanup patch passed React lifecycle and real Chromium color-scheme checks. Sources: https://registry.npmjs.org/@aws-amplify/ui-react-liveness/-/ui-react-liveness-3.5.1.tgz and https://github.com/ds300/patch-package . Live AWS and deployed behavior were not verified.