pnpm 12 audit is CPU-bound, not network-bound
pnpm audit got ~60x slower in 12.x and the fix starts with checking user CPU time, not the registry.
pnpm audit got ~60x slower in 12.x and the fix starts with checking user CPU time, not the registry.
Two commands, `pnpm view <pkg> dist-tags` and a GitHub advisory's affected ranges, show whether a security fix is backported to the major your consumers use, so an override stays patch-level instead of forcing a major bump.
A pnpm peer-resolution path dropped the update depth, retained nanoid 3.3.16, and made a full lockfile and node_modules refresh the clean no-override fix.
Starting with pnpm 11.19 in our build, `pnpm deploy --legacy` left workspace dependencies linked to source directories that the runtime image did not contain.
A recurring SyntaxError traced to a brace-expansion patch and an ESM export-shape mismatch: how moving minimatch to v10 removed one patch while a minimatch@3 compatibility patch remained necessary.
Seven pnpm releases shipped between 11.7 and 11.13.1, and the one that maps to my config is a peak-memory fix for the minimumReleaseAge and trustPolicy resolution path.
Caching the package manager store treats a symptom. A pull-through proxy registry is the layer where cross-runner dependency caching actually compounds.
A single broken dependency blocked 20 updates in one Renovate PR. Three config changes prevent it from happening again.
Five cache mechanisms layered on a single self-hosted GitLab runner to keep a Java + Node + Python + React Native monorepo fast without standing up an external cache service.
Renovate PRs fail CI when Prettier reformats the lockfile. The fix is one line.
Pulling four mature JS apps into one root pnpm workspace with a shared lockfile failed for six concrete reasons; here's the narrower shape that survived.
When pnpm audit signatures flags a package as invalid with reason 'terminated', the packument HTTP fetch failed, not a signature failure or tampering.
After re-deriving the same pnpm audit remediation decision tree across five JS trees one too many times, I packaged it as an agent skill that runs the process instead of rediscovering it.
Renovate updates mise.toml via the mise manager and packageManager via the npm manager. They land in different PRs. I treated that as defense-in-depth until they disagreed.
Renovate's vulnerability alerts only cover direct dependencies in npm and pip. Here is the CI-gate and manual-remediation pattern that catches the rest, and why I run Renovate without Dependabot.
Committing a self-contained mise bootstrap, mounting persistent cache volumes in Dagger, and enforcing the lockfile everywhere so mise.toml is the only source of truth for the toolchain.
Dagger modules install in isolation with a generated pnpm-workspace.yml that has no catalog. The project root's workspace file is never read.
Using pnpm catalog to turn two workspace packages with divergent TypeScript and ESLint versions into a single source of truth. Covers a Remotion peer-dep fix and a minimumReleaseAge interaction.
Six pnpm releases shipped while my project was frozen at 11.1.2. Two of them added security controls I should have adopted sooner.
A systematic approach to eliminate every known vulnerability and replace pnpm monkey-patches with proper supply-chain configuration.
Closing supply chain gaps in an existing Renovate setup with OSV scanning, SHA pin protection, and cooldown alignment complementing pnpm's minimumReleaseAge.
How to set up Renovate or Dependabot with cooldown policies that complement pnpm's minimumReleaseAge: automated patches without opening the door to compromised packages.
Your pnpm security config decays over time. minimumReleaseAgeExclude entries pile up, trustPolicyExclude entries become stale, and allowBuilds lists drift from reality. Here's how to catch it.
Trying to survive in the JS minefield