ci: do not run install hooks in the TypeScript 7 canary - #36
Merged
Conversation
The lane resolves `typescript@latest` on purpose — it is a canary against a moving target, and pinning it would remove the only thing it measures. So the unpinned install stays, and Scorecard's Pinned-Dependencies finding is accepted rather than satisfied. Checked against Scorecard's source: version pinning does not clear that check either, only a lockfile install does, and there is no way to mark a step intentionally unpinned. What can be improved without touching the purpose is the install itself. `--ignore-scripts` removes lifecycle-hook execution from the one unpinned install in this repository. The job's exposure was already small — it inherits `contents: read`, references no secrets and uploads no artefacts — and this takes out the remaining code path. Verified locally with the exact command: installs 7.0.2, and `tsc -b tsconfig.build.json --force` still exits 0. The comment now separates the two reasons for staying on 6.0.x. Only typescript-eslint declares a `typescript` range (`>=4.8.4 <6.1.0`), and it is the only dev dependency that declares one at all — vitest, vite and knip declare none — so it is the thing to re-check when it lifts. That the wider toolchain is not ready in practice is the other reason, and not one a peer range will tell you. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Follow-up on code scanning alert #4 (
Pinned-Dependencies,ci.yml:178, score 9/10).The alert is real, and the right answer is to keep the finding
The line it points at is
npm install --no-save typescript@7in the non-blockingtypescript7lane. The unpinnedness is the feature: the lane compiles the package against whatever npm'slatestresolves to today, so pinning it turns a canary into a fixed target and removes the only signal it produces.Verified rather than assumed:
isNpmUnpinnedDownloadreturns true fornpm installregardless of the specifier, false only fornpm ci, and there is no mechanism to mark a step intentionally unpinned.latestfor typescript is7.0.2; this repo builds~6.0.3;typescript-eslint@8.67.0declarestypescript >=4.8.4 <6.1.0.mainpassed, so TS7 compiles the package fine today.39e944d6, this branch's merge base. (The line number is off by one: therun:is on 177 and Scorecard attributes 178.)A dedicated lockfile plus
npm ciwould satisfy the check, but the canary would then track "whatever Dependabot last bumped" instead oflatest— reintroducing the lag the lane exists to remove — for a lane that is deliberately non-blocking.So the alert is dismissed as accepted, with that reasoning recorded on it.
What this PR does change
--ignore-scripts. The one unpinned install in this repository has no reason to run lifecycle hooks, and this removes that code path. The job's exposure was already narrow — it inheritscontents: read, references no secrets, uploads no artefacts, and iscontinue-on-error— so this is the last piece rather than the main one.Verified locally with the exact command:
typescript@7.0.2installs andtsc -b tsconfig.build.json --forceexits 0.Comment
Rewritten to separate the two reasons for staying on 6.0.x. Only
typescript-eslint(and its parser) declares atypescriptpeer range — vitest, vite,@vitest/coverage-v8and knip declare none — so it is the one to re-check when it lifts. That the wider toolchain is not ready in practice is a separate reason, and not one a peer range will tell you.🤖 Generated with Claude Code