Strict symlink isolation versus selective hoisting for legacy tool compatibility in pnpm workspaces

A pnpm workspace stores packages once in a content-addressable store and creates per-project node_modules via symlinks. Strict isolation preserves deterministic resolution and disk efficiency, but changes resolution paths compared to a flat layout.

Selective hoisting via public hoist patterns and node linker options can expose specific packages at the workspace root to satisfy tools that assume top-level availability. This alters module resolution semantics and can vary with operating system and linker mode.

Concurrent installs share the store and lockfile, which can create contention and perceived latency even when work is deduplicated. The unresolved decision is which packages to hoist or which peer dependency rules to relax for a given workspace without a reproducible rule, requiring per-tool validation.

What criteria define a minimal hoist set that satisfies a legacy tool without weakening isolation? How does hoisting interact with symlink resolution under different node linker modes? Is there a documented way to audit which packages a tool requires at the workspace root?