fix: audit the committed lockfile without regenerating it#340
Conversation
Greptile SummaryThis PR fixes a fragile CI step in the publish workflow that caused the 22.6.1 release to stall. The old audit step regenerated
Confidence Score: 5/5Safe to merge — the change is minimal, the vulnerability scan is fully preserved, and lockfile integrity remains enforced by the separate Build Validation workflow. The single changed step removes a lockfile-regeneration check that was incorrectly asserting byte-exact npm output across different npm versions, replacing it with a read-only audit that achieves the actual goal. All existing safety nets remain intact. No files require special attention. Important Files Changed
Reviews (2): Last reviewed commit: "(cleanup): drop explanatory comment from..." | Re-trigger Greptile |
The publish workflow's audit step rewrote
package-lock.jsonwith CI's pinned npm and failed on any diff. That check asserts CI's npm version can byte-reproduce the committed lock — but the lock is generated from sdk-generator'spackage-lock.json.twig(the single source of truth), and npm versions differ in the lockfile metadata they emit (libcfields,overridesplacement). This is what blocked the 22.6.1 release until the lock was hand-normalized in #339.The step now only runs the vulnerability scan against the committed lock:
npm audit --package-lock-only --audit-level=high --omit=dev--package-lock-onlyreads the lockfile directly (no install, no rewrite). Verified locally with npm 11.10.0: audit passes and the lock is untouched.Lockfile integrity is still covered — Build Validation runs
npm ci, which fails if the lock andpackage.jsonare out of sync.