Skip to content

fix(release): regenerate lockfile after version bump and guard it #189

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
KeKs0r merged 1 commit into from
Jul 9, 2026
Merged

fix(release): regenerate lockfile after version bump and guard it #189

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 16 additions & 2 deletions scripts/manual-release.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,8 @@
* - default: enters beta prerelease mode if needed
* - --stable: exits prerelease mode so versions graduate to GA
* 3. Applies pending changesets (version bump) if they exist,
* or detects already-bumped versions from a prior run
* or detects already-bumped versions from a prior run, then
* regenerates the lockfile so it matches the bumped versions
* 4. Runs quality gates (typecheck, lint, test, build)
* 5. Runs release guards (internal workspace deps + packed tarballs)
* 6. Publishes all public workspace packages via `bun publish`:
Expand Down Expand Up @@ -147,7 +148,7 @@
* In that case, the consumed entries are cleared from pre.json so
* `changeset version` re-processes them and bumps to the next beta.
*/
function applyPendingChangesets(dryRun: boolean, stable: boolean): boolean {

Check warning on line 151 in scripts/manual-release.ts

View workflow job for this annotation

GitHub Actions / verify

High CRAP score (moderate) 

Function 'applyPendingChangesets' has a CRAP score of 30.0 (threshold: 30.0).

  • Severity: moderate
  • Cyclomatic: 5
  • Cognitive: 4
  • CRAP: 30.0 (threshold: 30.0)
  • Lines: 56

CRAP combines complexity with coverage: high CRAP means changes here carry high risk.
Consider adding tests, simplifying the function, or both.
const result = collectChangesetValidation()

if (result.files.length === 0) {
Expand Down Expand Up @@ -192,6 +193,15 @@
}

runCommand('bun', ['run', 'version-packages'])

// `changeset version` rewrites package.json versions but never touches the
// lockfile. examples/* pin sibling chkit packages to exact published betas,
// so once the workspace version moves past that pin bun can no longer dedupe
// them onto the local copies and must record fresh registry resolutions.
// Regenerate the lockfile here so the release commit carries them; otherwise
// CI's `bun install --frozen-lockfile` rejects the stale lockfile on main.
runCommand('bun', ['install', '--lockfile-only'])

return true
}

Expand Down Expand Up @@ -595,8 +605,12 @@
*/
function runReleaseGuards(): void {
logLine(
'Running release guards (internal workspace deps + packed tarballs)...',
'Running release guards (lockfile + internal workspace deps + packed tarballs)...',
)
// Fail here if the committed lockfile does not satisfy the bumped versions —
// the same check CI runs on main. This catches a stale lockfile before the
// release is pushed rather than after.
runCommand('bun', ['install', '--frozen-lockfile'])
runCommand('bun', ['run', 'check:workspace-deps'])
runCommand('bun', ['run', 'check:packed-deps'])
}
Expand Down
Loading