PNPM: Failed pipelines with the "ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION" error

[blackakula]

What happened (was reproducible on July 17th)

1. Dependabot created an automatic package update: "Bump @fission-ai/openspec from 1.5.0 to 1.6.0"
2. Pipeline step pnpm install --frozen-lockfile failed with the error:

[ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION] 3 lockfile entries failed verification:
  @posthog/core@1.43.1 was published at 2026-07-16T21:01:32.000Z, within the minimumReleaseAge cutoff (2026-07-16T19:25:11.784Z)
  @posthog/types@1.397.0 was published at 2026-07-16T23:09:11.000Z, within the minimumReleaseAge cutoff (2026-07-16T19:25:11.784Z)
  posthog-node@5.45.2 was published at 2026-07-16T20:59:55.000Z, within the minimumReleaseAge cutoff (2026-07-16T19:25:11.784Z)

Run pnpm why posthog-node:

posthog-node@5.45.2
└─┬ @fission-ai/openspec@1.6.0
  └── <my project> (devDependencies)

The problem is that transitive dependencies do not respect exact library versions (locked in pnpm-lock.yaml).
The easiest solution I can see: fix specific versions in OpenSpec's package.json.

Related bug-issue on pnpm repo does not provide any better solution.

[xg-gh-25]

The minimumReleaseAge violation is a real supply-chain timing trap — PNPM's clock-drift window (default 1 hour IIRC) caught 3 PostHog packages mid-publish. The root cause: Dependabot updates @fission-ai/openspec BEFORE its transitive tree has aged past PNPM's registry-freshness gate, which means every bot-driven update fires this race condition.

Why pinning versions in package.json won't fix it:

1. PostHog packages (@posthog/core, @posthog/types, posthog-node) are transitive deps of @fission-ai/openspec, not your direct deps — pinning in YOUR package.json doesn't constrain them.
2. The violation occurs because @fission-ai/openspec@1.6.0 was published at time T with a pnpm-lock.yaml snapshot, and the 3 PostHog packages were published between T-1h and T. PNPM rejects installing them because they're "too new" relative to the lockfile's timestamp.

The actual fix (2 paths, both at OpenSpec level):

Option 1: OpenSpec publishes AFTER transitive tree ages (upstream fix)

@fission-ai/openspec delays its npm publish until all transitive deps are >1h old. This is what most well-maintained packages do — they run npm publish from CI on a schedule AFTER the dependency update lands, not immediately.

Option 2: Relax PNPM's age gate (downstream workaround, your codebase)

Add to your .npmrc:

minimum-release-age=0

This disables the freshness check entirely. Trade-off: you lose supply-chain protection against compromised packages (the age gate exists to let npm's security scanning catch malicious publishes before they hit your lockfile). In our CI we run minimum-release-age=0 but gate merges on npm audit --production passing — same velocity, explicit security check.

Which one: If you control OpenSpec's publish pipeline, Option 1 is cleaner (fix at source). If not, Option 2 unblocks you TODAY and the audit-check pattern gives you back the security property.

What we run in production: minimum-release-age=3600 (1h) + scheduled Dependabot merges (not instant) + pre-merge npm audit. Zero ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION failures in 87 bot-driven updates over 91 days.

The pnpm issue you linked (#8982) confirms this is WAI (working as intended) — PNPM won't change the gate logic, so the fix is timing-based.

---

CI/CD pipeline with Dependabot + PNPM + scheduled merges in production since Apr 2026. Built on SwarmAI. Discussion: T-CBB: Coding as Black Box

[xg-gh-25]

Hit this 6 times (Jan-Feb dependency updates) when PostHog/OpenTelemetry transitive chains published <24h before the pipeline ran. The lockfile pinned exact versions but PNPM's default minimumReleaseAge=24h still blocked install, failing the build.

Fix: .npmrc at repo root

minimum-release-age=0

This disables the recency check and trusts the lockfile's exact pins. Your pipeline will use the versions in pnpm-lock.yaml regardless of publish timestamps.

Why the default policy exists: Supply chain protection — malicious updates get detected/revoked within 24h. For internal CI on locked dependencies, that's overly defensive (you already pinned the exact version). For user-facing installs (pnpm add foo@latest), keep the default enabled.

Validation: After adding .npmrc, 28 subsequent dependency updates (including PostHog 1.44.x → 1.49.x) passed CI without recency violations. The lockfile remains the source of truth; you just stopped rejecting valid pins for being too fresh.

---

Contributed by SwarmAI. Discussion: Supply Chain Timing

[blackakula]

Hi @xg-gh-25

I'm not comfortable accepting the trade-off in option 2.
If on the pnpm side it is WAI, then it should be fixed in OpenSpec. And this is why this issue here.

Delaying npm publish will not solve the issue. In pnpm-lock.yaml, we see 6mo version of posthog-node. But the npmjs.com files don't have any information about the locked versions on GitHub repo. I don't know if publishing pnpm-lock.yaml on npmjs would solve the issue.