Skip to content

Adopt org pnpm supply-chain policy (recipe A) - #342

Merged
pyramation merged 1 commit into
mainfrom
feat/pnpm-policy
Aug 6, 2026
Merged

Adopt org pnpm supply-chain policy (recipe A)#342
pyramation merged 1 commit into
mainfrom
feat/pnpm-policy

Conversation

@pyramation

Copy link
Copy Markdown
Collaborator

Rolls this repo onto the org pnpm supply-chain policy. Part of the queue in constructive-io/constructive-planning#1464 (recipe A).

What changes

  • pnpm-policy.yaml (new): minimumReleaseAge: 2d, blockExoticSubdeps: true (this workspace resolves zero git/tarball transitive deps, verified against the lockfile), intersect: true, maintainer pyramation, and 6 owned scopes (@constructive-io, @constructive-db, @launchql, @pgpm, @pgpmjs, @pgsql).
  • pnpm-workspace.yaml — generated block: 6 scope globs + 7 first-party packages exempt from the wait (git-changed, libpg-query, makage, nested-obj, pnpm-policy, strfy-js, yamlize), 884 omitted since this workspace does not resolve them. Confirmed intersect: true is doing real work: total inventory is 891 first-party names (7 + 884), and this parser monorepo only pulls in 7 of them — far fewer than the ~1100-package org inventory the task flagged as a risk.
  • allowBuilds — three packages were already running install scripts pre-policy and now need an explicit reason:
    • nx: native postinstall step (downloads/links its native project-graph daemon binary)
    • unrs-resolver: ships a native (Rust/N-API) module resolver binary that must be built/linked on install
    • @launchql/protobufjs: protobufjs's own postinstall (environment/feature detection for the protobuf.js runtime, no native compile)
  • package.json@constructive-io/pnpm-policy pinned exactly at 0.2.1 (not ^0.2.1), so an inventory bump shows as a visible diff instead of silently widening the exemption list. pnpm-policy CLI added as ^0.2.2. Added policy / policy:check scripts.
  • .github/workflows/run-tests.yaml — added a pnpm run policy:check step right after the existing pnpm install step in the (only) parser-tests job.
  • pnpm-lock.yaml — resolves the two new devDependencies. Note: pnpm also reformatted the file's YAML quoting style (double → single quotes) as a side effect of running install with the local pnpm toolchain (11.11) vs whatever generated the file previously — pure formatting noise, pnpm install --frozen-lockfile still passes.

Verification (all run and read, not assumed)

  • pnpm run policy:checkpnpm-workspace.yaml matches the policy
  • pnpm install --frozen-lockfile → succeeds, no ignored-builds errors ✓
  • pnpm run policy run twice → pnpm-workspace.yaml byte-identical both times (shasum matched) ✓

Deviations / notes

  • CI's pnpm pin (v9) predates this feature set. .github/workflows/run-tests.yaml pins pnpm/action-setup@v4 to version: 9. pnpm's native minimumReleaseAge / blockExoticSubdeps / allowBuilds enforcement requires pnpm ≥ 10.16 (allowBuilds is the newer key name for that version; older pnpm used onlyBuiltDependencies). The repo has no packageManager field pinning a version anywhere, so I generated with the modern default key (allowBuilds), matching the toolchain actually used for local installs (pnpm 11.11) and by policy:check (a plain Node CLI that only diffs YAML, so it still catches manual drift in CI regardless of pnpm version). What it does not do under the current pnpm 9 pin: pnpm itself won't actively enforce the release-age wait or build-script gating during CI's pnpm install step, since v9 predates those pnpm-native features entirely. Bumping CI's pnpm pin to ≥10.16 was out of scope for this recipe rollout (a separate, matrix-wide change to an already-passing test workflow) — flagging it here as a natural follow-up rather than making it silently.
  • pnpm-policy generate (via the underlying pnpm add/pnpm install) triggers pnpm's own ERR_PNPM_IGNORED_BUILDS auto-stub behavior, which writes a placeholder allowBuilds: {pkg: "set this to true or false"} block into pnpm-workspace.yaml outside pnpm-policy's managed section. That's pnpm 11 itself, not pnpm-policy. Removed the stray stub by hand each time it appeared; the committed file has none.

Do not merge — for review only.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CEswUi4ANuB58rva48aHge

Third-party releases now wait 2 days before install: a compromised
release is normally reported and yanked within hours, so the wait
catches it without stalling legitimate upgrades. First-party packages
(our own scopes/maintainer) skip the wait since we control what we
publish. The exemption list in pnpm-workspace.yaml is generated from
the pinned @constructive-io/pnpm-policy inventory package, not
hand-maintained, so it can't silently drift out of sync with what we
actually own.

- pnpm-policy.yaml: 2d minimumReleaseAge, blockExoticSubdeps,
  intersect: true (only emits the ~7 first-party packages this
  lockfile resolves out of ~891 in the inventory).
- allowBuilds: nx, unrs-resolver, @launchql/protobufjs — each already
  ran an install script pre-policy; documented with a real reason.
- @constructive-io/pnpm-policy pinned exact (0.2.1) so an inventory
  bump shows as a visible diff instead of silently widening the
  exemption list.
- Wired pnpm run policy:check into the existing Parser tests workflow,
  right after its pnpm install step.

Part of constructive-io/constructive-planning#1464 (recipe A rollout).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CEswUi4ANuB58rva48aHge
@socket-security

Copy link
Copy Markdown

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff Package Supply Chain
Security
Vulnerability Quality Maintenance License
Added@​constructive-io/​pnpm-policy@​0.2.17610010091100
Addedpnpm-policy@​0.2.27610010090100

View full report

@pyramation
pyramation merged commit 7685f9e into main Aug 6, 2026
15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant