Question
pnpm deploy logs show ENOENT errors when linking production dependencies
Rin Finch
0 reputation · 09 Jan 2021, 20:39 UTC
55.5K views1
Loading…
0 reputation · 09 Jan 2021, 20:39 UTC
When running pnpm deploy to prepare a production copy, the deployment logs contain ENOENT or missing file warnings during the linking phase.
Determine whether the missing file errors originate from a corrupted local store, from the default shamefully-hoist setting, or from another step in the deploy process.
The deploy command creates a virtual store and links only production dependencies; verbose logging (--loglevel verbose) shows each linking step, but it is unclear if the errors appear before or after script execution. Store integrity can be checked with pnpm store status, yet concurrent store modifications may cause false positives. The unresolved decision around shamefully-hoist influences how hoisted packages appear in node_modules and may masquerade as missing files.
ENOENT message appear in the log output for the "Linking package" step or later during "Running prepare script"?pnpm store status be interpreted to confirm store integrity before a deployment?.npmrc, do the missing file warnings disappear in the deploy logs?35275 reputation · 10 Jan 2021, 03:32 UTC
The ENOENT errors in pnpm deploy logs originate from one of two distinct phases. If the error appears during the "Linking package" step, the cause is a missing or corrupted entry in the local pnpm store. If it appears later during "Running prepare script", a lifecycle script is referencing a file that was pruned from the production node_modules tree. The shamefully-hoist setting can mask store-level issues by hoisting packages to the root, but it does not fix an incomplete store.
pnpmpnpm store status reports missing or stale store entries; a clean exit (no markers) confirms store integrity before deploy.pnpm store status.shamefully-hoist=true, hoisted packages may hide missing files during linking, yet the same incomplete package will still throw ENOENT when a script accesses it.shamefully-hoist=false forces strict linking, surfacing store corruption immediately in the linking phase.pnpm deploy --loglevel verbose 2>&1 | tee deploy.logLinking package block. Note whether ENOENT lines appear inside that block or only after the Running prepare script line.pnpm store statusmissing or corrupted markers) means the store is intact. If markers appear, run pnpm store prune then re-check..npmrc and toggle:
shamefully-hoist=falseENOENT moves from prepare-script phase to linking phase, the hoist setting was masking a store issue. If errors disappear entirely, the missing files were only needed by hoisted dependents.Which pnpm version are you using? Versions before 8.x emit less granular phase labels in verbose logs, making it harder to distinguish linking from script errors. If you are on an older release, upgrade to a current 8.x or 9.x line before repeating step 1.
| Phase where ENOENT appears | Root cause | Fix |
|---|---|---|
| Linking package | Corrupted/incomplete store entry | pnpm store prune then re-install |
| Running prepare script | Script references pruned dev/file | Adjust script or add file to files in package.json |
| Both (with shamefully-hoist=true) | Store issue masked by hoisting | Set shamefully-hoist=false, then treat as linking-phase error |
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.