pnpm & CI/CD Pipelines: Does lockfile consistency influence deployment reproducibility?

When a deployment fails after passing all local tests, the first step is to inspect the CI logs for clues that point to pnpm’s lockfile or hoisting behavior. The goal is to determine whether a mismatch between the lockfile and the resolved dependency tree, or a silent link‑creation failure, is the root cause.

pnpm’s content‑addressable store and use of hard links (or Windows junctions) can silently drop modules on agents that lack proper link support or have aggressive antivirus policies. Additionally, selective hoisting moves some dependencies to the root of node_modules, which may not be declared in package.json> and can cause missing‑module errors that only surface in the deployment environment.

Because the pnpm install --frozen-lockfile command aborts on any mismatch, the error output often references a generic lockfile inconsistency without pinpointing the offending package. This ambiguity, combined with OS‑specific link behavior, makes log‑based diagnosis challenging.

What log entries best indicate a missing module caused by pnpm’s hoisting? How can we detect silent link failures on CI agents that have restrictive antivirus or filesystem settings? Does using --frozen-lockfile guarantee reproducibility across Windows and Linux agents, or are there hidden pitfalls that still need to be addressed?