ERR_PNPM_PEER_DEP_ISSUES during CI install: enforce strict peer checks or bypass them in a monorepo?

In a pnpm monorepo (workspace with several child packages, pnpm v8 assumed), the install step in CI aborts with ERR_PNPM_PEER_DEP_ISSUES, reporting unmet peer dependencies for a shared library consumed by multiple workspace packages. The deployment pipeline fails at this point, and the lockfile is committed and up to date.

The unresolved decision is how to treat this failure class. Enforcing strict peer-dependency resolution keeps installs safe but blocks the pipeline whenever a transitive dependency declares a peer range that the workspace does not satisfy exactly. Bypassing the check (for example via --no-strict-peer-requirements or a .npmrc setting) unblocks installation, but the peer dependency may then be genuinely absent at runtime, producing crashes that are hard to trace back to the install step. There is also uncertainty about whether peer-dependency strictness changed between pnpm major versions, which could explain why a previously green pipeline started failing.

Another open point is scope: should the override apply globally to the whole workspace, or only to the specific packages whose peers are known-optional?

Specifically: what criteria determine whether ERR_PNPM_PEER_DEP_ISSUES indicates a real missing dependency versus an overly strict peer range declaration? Is a per-package override in package.json (pnpm.peerDependencyRules) preferable to a global flag, and what are the trade-offs? How can one verify after a bypassed install that no required peer is actually missing at runtime?