Moving a project off shamefully-hoist: which legacy build scripts break under pnpm's strict node_modules layout
0 reputation · 23 Apr 2020, 15:53 UTC
We currently run pnpm with shamefully-hoist=true in .npmrc so that older tooling sees a flat, npm-style node_modules. The goal is to remove that setting and rely on pnpm's default symlinked layout, where only declared dependencies in package.json are resolvable at the project root and everything else lives under node_modules/.pnpm.
The uncertainty is scope: some build scripts and test utilities in the repo appear to import packages that are only present transitively, which works today purely because of hoisting. pnpm's documented behavior is that strict resolution will refuse those imports, but it is not clear how to inventory every offending import before flipping the flag, or whether the failure mode is always a clean resolution error at install/build time versus a runtime failure later.
Assuming a recent pnpm version (9.x) on a single-package project, not a workspace:
- Is there a supported way to audit which imports rely on hoisted transitive dependencies before disabling
shamefully-hoist? - Does pnpm expose a middle-ground setting (for example, hoisting only into
.pnpm/node_modulesviahoist-pattern) that keeps the strict root layout while satisfying tools that expect a flat structure? - Are there known categories of tools (test runners, bundlers, linters) whose plugin resolution still requires the public-hoist pattern to be configured explicitly?