fix(release): support aube-only checkouts without package-lock.json#101
Merged
Conversation
After the aube migration in #91 the repo no longer ships a `package-lock.json`, but `scripts/release-helpers.mjs` and `scripts/release-prep.mjs` still hardcoded it as a required file: - `readPackageVersions` did `readJsonFile('package-lock.json')` unconditionally and failed with ENOENT on the current main. - `assertPackageVersionsMatch` then asserted the lockfile's `version` and `packages[""].version` matched `package.json.version`. - `release-prep.mjs` froze `VERSION_FILE_PATHS` as `['package.json', 'package-lock.json']` at module scope and staged both, so even if the version-match assertion were relaxed, the staging step would still fail because `package-lock.json` does not exist. The net effect was that `npm run release:prep` (and, by inheritance, `npm run release:finalize`) failed end-to-end on `main`, blocking the documented release flow. This change makes the lockfile path optional: - `readPackageVersions` checks `existsSync('package-lock.json')`. When present it still parses + returns the lockfile version fields; otherwise it returns `hasPackageLock: false` with null lockfile versions and only validates `package.json`. - `assertPackageVersionsMatch` only runs the lockfile-coherence assertions when `hasPackageLock` is true. - `release-prep.mjs` computes the version-file allowlist at runtime via `resolveVersionFilePaths(root)`. On an aube-only checkout this resolves to `['package.json']`; on a checkout that still carries `package-lock.json` it stays at `['package.json', 'package-lock.json']`, preserving the prior behavior for downstream consumers that re-introduce an npm lockfile. `release-finalize.mjs` consumes `assertPackageVersionsMatch` and inherits the fix without changes. Tests ----- `createTempRepo` / `writePackageFiles` gain an `includePackageLock` option (default `true`), and two new integration test cases cover the aube-only path: - `prepares a release on an aube-only checkout (no package-lock.json)` asserts the prep commit's diff is exactly `['package.json']` and that `package.json.version` matches the requested release version. - `finalizes on an aube-only checkout (no package-lock.json)` asserts the annotated tag is created and pushed. The pre-existing npm-lockfile test cases are unchanged and continue to assert the two-file diff + readVersions triple. All 27 release-scripts tests pass. Format, lint, and typecheck are clean. Docs ---- `docs/RELEASE-PROCESS.md` is updated so the changelog-mode prose and the manual-prep fallback no longer claim that `package-lock.json` is always part of the prep commit; the fallback snippets now stage `package-lock.json` only when it actually exists. Change-Id: Idfb4bbdde5d222c4f0f9096d650bbbc2f6d5f9c9 Signed-off-by: Thomas Kosiewski <tk@coder.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
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.
Summary
After the aube migration in #91 the repo no longer ships a
package-lock.json, but the release-prep tooling still required one. The net effect was thatnpm run release:prep(andnpm run release:finalize, which calls the same helpers) failed end-to-end on the currentmain, blocking the documented release flow:This PR makes the lockfile path optional so the scripts work on aube-only checkouts while still supporting the npm-lockfile path for downstream consumers that re-introduce one.
Why this blocks v0.2.0
I hit this while running the
release:prepstep of the v0.2.0 release sequence (Step 3 of plan tracked in #99). Without this fix the documentedrelease:prep/release:finalizeflow is broken onmain, so it needs to land before the version-bump PR.Changes
scripts/release-helpers.mjsreadPackageVersionschecksexistsSync('package-lock.json'). When present it still parses + returns the lockfile version fields; otherwise it returnshasPackageLock: falsewith null lockfile versions and only validatespackage.json.assertPackageVersionsMatchonly runs the lockfile-coherence assertions whenhasPackageLockis true.scripts/release-prep.mjsVERSION_FILE_PATHSconstant withresolveVersionFilePaths(root)computed at runtime. On an aube-only checkout this resolves to['package.json']; on a checkout that still carriespackage-lock.jsonit stays at['package.json', 'package-lock.json'], preserving the prior behavior.scripts/release-finalize.mjsassertPackageVersionsMatchand inherits the fix.test/integration/release-scripts.test.tscreateTempRepo/writePackageFilesgain anincludePackageLockoption (default `true`).docs/RELEASE-PROCESS.md`CHANGELOG.md`
Test plan
🤖 Generated with Claude Code