Repository navigation
Support npm install-strategy=linked (.store directory layout) #595
Description
Bug report
When npm is configured with install-strategy=linked (an experimental feature in npm), packages are stored in node_modules/.store/<pkg>@<version>-<hash>/node_modules/<pkg>/ and symlinked into consuming packages' node_modules/. patch-package cannot find packages at these paths and fails to apply patches.
Current Behavior
With install-strategy=linked in .npmrc, running patch-package in postinstall fails with:
Error: Patch file found for package lighthouse which is not present at node_modules/@wordpress/e2e-test-utils-playwright/node_modules/lighthouse
The package exists, but at a different path:
node_modules/.store/lighthouse@12.2.2-E1oDY3hhcKvr16czLc4uyw/node_modules/lighthouse/
A symlink exists at the expected nested path, but it points into .store/:
packages/e2e-test-utils-playwright/node_modules/lighthouse ->
../../../node_modules/.store/lighthouse@12.2.2-E1oDY3hhcKvr16czLc4uyw/node_modules/lighthouse
This affects both nested patches (parent++child+version.patch) and, in monorepo/workspace setups, any packages whose dependencies are stored exclusively in .store/.
Expected behavior
patch-package should resolve the actual package location by following symlinks or by searching the .store/ directory when the traditional node_modules/ path doesn't contain the package directly.
Possible Solution
When looking up a package to patch, if the expected node_modules/<pkg> path is a symlink, follow it to find the real package directory and apply the patch there. Alternatively, add support for searching node_modules/.store/ for <pkg>@<version>-* entries.
This is related to #277 (monorepo hoisting) in that both involve packages not being at the path patch-package expects, but the root cause here is the npm linked install strategy's .store/ layout rather than workspace hoisting.
Context
npm's install-strategy=linked is an experimental feature that deduplicates packages by storing them in a content-addressed .store/ directory and creating symlinks. As this strategy matures and sees wider adoption, patch-package will need to handle this layout.
Our workaround is a custom apply-patches.mjs script that:
- Parses patch filenames to extract package name and version
- Looks up the package in
node_modules/.store/<pkg>@<version>-*/node_modules/<pkg>/ - Rewrites diff paths in the patch to target the actual
.store/location - Applies patches using
git apply --ignore-whitespace
Your Environment
| Software | Version(s) |
|---|---|
| patch-package | 8.0.0 |
| npm | 10.9.5 |
| node | 20.x+ |
Activity
jellelicht commentedon Apr 15, 2026
I can confirm this works for our monorepo, with (potentially) hoisted deps, thanks @manzoorwanijk
What {c,sh}ould happen if several workspaces (or a workspace and the root
package.json) want to patch the same package?manzoorwanijk commentedon Apr 16, 2026
The patch is usually applied to a specific version which is stored in a hashed path in the store. So if the workspaces share the same version of the dependency to patch, it needs only one patch in the store.
jellelicht commentedon May 5, 2026
@manzoorwanijk I would be using this for the monorepo support, not the store support, but either way it's probably a case of user error if you try to patch the same thing multiple times.
RFC: Native Dependency Patching (#862)