pnpm workspace: phantom dependency risk when using hoist-pattern

In a pnpm workspace, the hoist-pattern option can be used to lift specific packages into the root node_modules. While this may accommodate legacy tooling that expects a global installation, it also bypasses pnpm’s strict peer‑dependency validation. The result is a phantom dependency that exists only because it was hoisted, not because a consumer explicitly declared it. This behavior conflicts with pnpm’s documented goal of preventing unused or undeclared dependencies from appearing in a project’s dependency graph.

The core uncertainty lies in whether a selective hoist should be considered safe when it introduces a dependency that is not listed in any workspace package’s peerDependencies or dependencies. If a consumer can require the hoisted package at runtime, does that mean the package should be treated as a legitimate dependency, or should pnpm enforce a stricter rule that rejects the hoist altogether?

What are the best practices for balancing the need to support legacy tooling with pnpm’s strict dependency enforcement? Under what conditions, if any, is it acceptable to use hoist-pattern without compromising the integrity of the workspace? How can a workspace designer detect and mitigate phantom dependencies introduced by selective hoisting?