chore: add minimumReleaseAge to defend against supply chain attacks

[jonathanprozzi]

Summary

• Add minimumReleaseAge: 10080 (7 days) to pnpm-workspace.yaml
• Prevents pnpm from installing any package version published less than 7 days ago
• Defense-in-depth against supply chain attacks using compromised maintainer credentials
• Uses pnpm-workspace.yaml instead of .npmrc since .npmrc is in .gitignore
• Can be overridden per-package via minimumReleaseAgeExclude if needed

References

• https://socket.dev/blog/axios-npm-package-compromised
• https://pnpm.io/settings#minimum-release-age

Test plan

• pnpm-workspace.yaml updated with correct config
• No .npmrc force-add needed

[claude]

PR Review: chore: add minimumReleaseAge to defend against supply chain attacks

Overall this is a well-motivated, low-risk security hardening change. A few notes:

Correctness ✅

10080 minutes = 7 days exactly (7 × 24 × 60). The math checks out and matches the stated intent.

Compatibility ✅

minimum-release-age was introduced in pnpm 9. The repo requires pnpm >= 9.11.0, so this setting will be recognized without issues.

Developer Experience — Worth Noting

This will silently block pnpm install (or pnpm add) if a resolution includes a package version published less than 7 days ago. pnpm will emit an error like:

ERR_PNPM_MINIMUM_RELEASE_AGE  Cannot install <pkg>@<version> because it was released less than 10080 minutes ago

Consider documenting in the project README or a contributing guide how a developer (or CI) should handle this when they legitimately need a very fresh release (e.g., a critical security patch shipped days ago). The PR description mentions minimumReleaseAgeExclude in pnpm-workspace.yaml, but that config isn't wired up yet — a brief note for contributors on how to use it would reduce friction.

Security Value ✅

This is a solid defense-in-depth measure. The 7-day window gives time for the community to catch typosquatting or compromised-maintainer attacks before they land in the codebase. Good precedent to set.

Minor Suggestions

• No trailing newline in .npmrc — most linters/editors expect one. Consider adding it to avoid diffs on auto-format.
• If the team ever decides to tighten controls further, pnpm also supports audit=true in .npmrc to run pnpm audit on every install.

No blocking issues. This is a good, incremental security improvement.

[claude]

PR Review: chore: add minimumReleaseAge to defend against supply chain attacks

This is a well-motivated, low-risk security hardening change. Notes below:

Correctness ✅

10080 minutes = 7 days exactly (7 × 24 × 60). The math checks out and matches the stated intent.

Compatibility ✅

minimumReleaseAge was introduced in pnpm 9. The repo requires pnpm >= 9.11.0, so this setting will be recognized without issues.

YAML Format — Minor Issue

The added lines lack a trailing newline at the end of pnpm-workspace.yaml. Most editors and linters expect files to end with a newline. Worth adding to avoid noisy diffs on auto-format.

Developer Experience — Worth Documenting

When a resolution includes a package published less than 7 days ago, pnpm will error:

ERR_PNPM_MINIMUM_RELEASE_AGE  Cannot install <pkg>@<version> because it was released less than 10080 minutes ago

The PR mentions minimumReleaseAgeExclude as the escape hatch, but it isn't wired up here. A brief comment in pnpm-workspace.yaml or the contributing guide showing how to use it would reduce friction for developers (or CI) that legitimately need a fresh release (e.g., a just-shipped security patch):

# To allow a specific package to bypass the age check:
# minimumReleaseAgeExclude:
#   - some-pkg

Security Value ✅

Solid defense-in-depth. The 7-day window gives the community time to catch typosquatting or compromised-maintainer attacks before they land. Good precedent to set for the monorepo.

No blocking issues. This is a good, incremental supply chain security improvement.

[jonathanprozzi]

@Vitalsine85 @0xjojikun vis for when you have a moment