TS lane: in-lane allowScripts approvals + a clean dev-tree audit - #21
Merged
Conversation
…n-lane, and the audit runs clean Two findings from reading opendpp-node's sdk-regen CI logs end to end: - esbuild's postinstall ran on the CI runner unapproved. The lane had no allowScripts of its own, so behaviour depended on whichever parent directory the checkout happened to sit in (opendpp-node's CI nests this repo at sdk/, where npm walks up and finds THAT repo's allowScripts — pinned to versions this lockfile does not resolve). The approval list now travels with the lane: esbuild@0.27.2, esbuild@0.28.1, fsevents@2.3.3, exact-version-pinned so a bumped dep that runs install scripts must be re-approved here in the same change. - npm audit reported 5 advisories (1 low, 4 high), all devDependencies. esbuild 0.27.7 -> 0.27.2 clears GHSA-g7r4-m6w7-qqqr within tsup's declared ^0.27.0 (the 0.28 ceiling is tsup's, not ours). js-yaml is exact-pinned at 4.2.0 by @hey-api/json-schema-ref-parser@1.4.4 — a pin no range solver can route around — so the overrides floor lifts it to ^4.3.1 (GHSA-52cp-r559-cp3m, GHSA-5p4m-2wfm-xmqj). Dev-only either way: the generator toolchain never ships to consumers, and the generation input is first-party JSON, never untrusted YAML. Verified: npm ci clean (0 vulnerabilities, no script warnings), regenerate -> zero diff in src/generated, version lock, typecheck, build, tests 10 pass / 5 live-skipped.
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
2 participants
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.
Fixes the two findings from a close read of opendpp-node's
sdk-regenCI logs (PR gsavastano/opendpp-node#1619, run 32167793772).1. Install-script approval now travels with the lane
The
sdk-regenlog showed esbuild's postinstall executing on the CI runner with only a warning:typescript/had noallowScriptsof its own, so enforcement depended on whichever parent directory the checkout sat in. In opendpp-node's CI this repo is nested atsdk/, where npm walks up and finds that repo'sallowScripts— pinned toesbuild@0.28.2, a version this lockfile doesn't resolve — so the lane's actual script-carrying packages were uncovered, and npm's warn-mode ran them anyway.typescript/package.jsonnow carries its own exact-version approvals (esbuild@0.27.2,esbuild@0.28.1,fsevents@2.3.3). Bumping a dep that runs install scripts means re-approving it here in the same change.2. The 5 dev-tree advisories (1 low, 4 high) are cleared
0.27.7 → 0.27.2vianpm audit fix(GHSA-g7r4-m6w7-qqqr, dev-server file read). In-range for tsup's declared^0.27.0— the 0.28 ceiling is tsup's, not ours. tsx's nested0.28.1was already clean.→ 4.3.1via anoverridesfloor (GHSA-52cp-r559-cp3m, GHSA-5p4m-2wfm-xmqj). Required because@hey-api/json-schema-ref-parser@1.4.4exact-pinsjs-yaml: "4.2.0"— a pin no range solver can route around. Re-check whether the floor still binds when hey-api moves.Both are devDependencies of the generator toolchain — nothing here ships to SDK consumers, and the generation input is first-party JSON, never untrusted YAML.
Verified
npm ci: 0 vulnerabilities, no install-script warningsnpm run generate: zero diff insrc/generated(generator stays 0.99.0)typecheck✓,build✓, tests 10 pass / 5 live-skipped