chore(deps): bump aube to 1.10.4, sandcastle to 0.5.10; revert node to 25#91
Merged
Conversation
ThomasK33
force-pushed
the
update-deps
branch
2 times, most recently
from
746115e to
c18b746
Compare
ThomasK33
changed the title
ThomasK33
changed the title
Move from pnpm/npm lockfiles to aube-lock.yaml and add @parcel/watcher + msgpackr-extract to onlyBuiltDependencies. Change-Id: I0f9cf162ea1b2ca93b004d089b357d91d9de2df2 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Signed-off-by: Thomas Kosiewski <tk@coder.com>
6 tasks
ThomasK33
added a commit
that referenced
this pull request
May 13, 2026
…101) 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
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.
Summary
aube1.4.0 → 1.10.4 and migrate from pnpm/npm lockfiles toaube-lock.yaml@ai-hero/sandcastleto 0.5.10@parcel/watcherandmsgpackr-extracttoonlyBuiltDependenciesplaywright install chromiumstep fromtest-unitCI job (unit tests don't launch a browser)Why not Node 26?
playwright install chromiumhangs silently on Node 26 after the download completes — the zip extraction never finishes. This is a confirmed upstream bug: microsoft/playwright#40724. Root cause is a Node 26 stream lifecycle change that breaksyauzl'sfd-slicerdestroy path, causing async iteration to wait forever for acloseevent. The fix is merged to Playwrightmain(PR #40747) but not yet released. Upgrade back to Node 26 once Playwright ships the fix (expected v1.60.0+), and updatepackage.jsonenginesfrom<26to<27at the same time.