Roll out pnpm supply-chain policy (recipe A) - #114
Merged
Conversation
Adds pnpm-policy.yaml plus @constructive-io/pnpm-policy (pinned exact at 0.2.1) and its pnpm-policy generate/check CLI, which patch a managed block into pnpm-workspace.yaml. Third-party releases wait 2 days before install: a compromised release is normally reported and yanked within hours, so the short wait catches it without stalling upgrades. The exemption list (our scopes, first-party packages this lockfile resolves) is generated from the pinned inventory package rather than hand-maintained, so it can't drift out of sync with what we actually publish. The hand-listed `onlyBuiltDependencies: [nx]` is folded into the new policy's `allowBuilds`, alongside two more packages this lockfile newly resolves that also need to run install scripts (@launchql/protobufjs for protobuf codegen via pg-proto-parser, unrs-resolver as jest's native module resolver) — each with a real reason instead of a bare allowlist. Wires `pnpm run policy:check` into ci.yml right after the existing `pnpm install` step so a hand-edited pnpm-workspace.yaml or a stale policy fails CI instead of silently drifting. Ref: constructive-io/constructive-planning#1464
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
Rolls out the org's pnpm supply-chain policy (recipe A) to this repo.
pnpm-policy.yamlat the workspace root:minimumReleaseAge: 2d,blockExoticSubdeps: true,maintainers: [pyramation], our owned scopes (@constructive-io,@constructive-db,@launchql,@pgpm,@pgpmjs,@pgsql), and anallowBuildsmap with real reasons.@constructive-io/pnpm-policyas a dev dependency, pinned exact at0.2.1(the currently published version — no caret), pluspnpm-policy(the CLI, caret is fine there).pnpm run policy(pnpm-policy generate) andpnpm run policy:check(pnpm-policy check) scripts.pnpm-workspace.yamlnow carries a generatedManaged by pnpm-policyblock (minimumReleaseAge,minimumReleaseAgeExclude,blockExoticSubdeps,allowBuilds).nx carryover
This repo already hand-listed
onlyBuiltDependencies: [nx]. That key is deleted in this same commit;nxnow lives inallowBuildswith reasonnative task-runner binary. Two more packages this lockfile resolves also needed build approval and got real reasons instead of a bare allowlist:CI
Wired: added a
Check pnpm supply-chain policystep (pnpm run policy:check) right after the existingInstall(pnpm install) step in.github/workflows/ci.yml(the workflow with theBuildstep — there's no separate lint workflow).integration-test.ymlwas left alone since it has no natural attach point beyond a duplicate install.Deviation worth flagging: both workflows pin
pnpm/action-setup@v2withversion: 9. There's nopackageManagerfield inpackage.jsonpinning a version. pnpm 9 predates the build-approval gate entirely (it runs install scripts unconditionally regardless ofallowBuildsor the olderonlyBuiltDependencies), so the generated key name doesn't change CI's enforcement either way. I generated with the defaultallowBuildskey rather than--builds-key onlyBuiltDependencies, because that's what pnpm >= 10.16 (what a current local install actually resolves to via corepack) needs to gate builds correctly — verifiedonlyBuiltDependencies-only did not satisfy pnpm 11.11.0's native ignored-builds check locally (hard failure,ERR_PNPM_IGNORED_BUILDS), whileallowBuildsdoes. If CI's pnpm pin is ever raised past 10.16, no further change is needed. Noted in a comment at the top ofpnpm-policy.yaml.Verification (all run and passing)
Also confirmed
blockExoticSubdeps: trueis safe here — no transitive dependency resolves from git or a URL (checked the lockfile and everypackages/*/package.json; the only"git"hits arerepository.type: gitmetadata).Note on the lockfile diff
pnpm-lock.yaml's diff is large (~11.7k lines) but is almost entirely YAML quote-style reformatting (double quotes to single quotes) from installing with the locally available pnpm 11.11.0 rather than the pnpm 9 the lockfile was last written with — not a dependency-tree rewrite. The actual new entries are@constructive-io/pnpm-policy@0.2.1andpnpm-policy@0.2.2plus their transitive deps.Ref: constructive-io/constructive-planning#1464
🤖 Generated with Claude Code
https://claude.ai/code/session_01CEswUi4ANuB58rva48aHge