Skip to content

MAI-42: add lockfile sync step to auto-version-bump workflow#15

Merged
vsmash merged 3 commits into
developfrom
task/MAI-42_lockfile_sync_workflow
May 13, 2026
Merged

MAI-42: add lockfile sync step to auto-version-bump workflow#15
vsmash merged 3 commits into
developfrom
task/MAI-42_lockfile_sync_workflow

Conversation

@vsmash
Copy link
Copy Markdown
Owner

@vsmash vsmash commented May 13, 2026

Summary

Eliminates the recurring package-lock.json drift that has been reverted in six consecutive PRs (MAI-17, MAI-21, MAI-28, MAI-39, MAI-43, MAI-46).

The auto-version-bump workflow runs maiass -a patch which rewrites package.json's version field but doesn't run npm install. The lockfile therefore lags by one version on every release. Drift had grown to package.json 5.12.12 vs package-lock 5.9.55.

Two changes

1. Workflow gets a "Sync package-lock.json" step

.github/workflows/version-bump.yml now runs after maiass -a patch:

git pull --ff-only origin develop
npm install --package-lock-only --no-audit --no-fund
if ! git diff --quiet package-lock.json; then
  git add package-lock.json
  git commit -m "Sync package-lock.json with bumped version"
  git push origin develop
fi

--package-lock-only avoids installing node_modules (the bump job doesn't need them). The conditional commit means most runs after this catchup will be no-ops (one extra git diff --quiet per release).

2. One-time lockfile catchup

npm install --package-lock-only regenerated package-lock.json to 5.12.12. The diff is 33 lines (7+/26-) — version field + a small normalisation; no dependency tree changes.

Decisions captured

Per MAI-42's open questions (resolved with user 2026-05-14):

  • Q1: how to stop the drift? → Option A: add npm install to the workflow. No separate hygiene PR needed — this PR catches up and the workflow takes over.
  • Q2: engines.node floor? → Already at >=20 in package.json. No change needed; ticket was based on stale lockfile that suggested a bump was happening.

User's design rationale for engines.node (worth recording — saved to memory): "many devs will be working on sites with older node. let's support min 20. while maiass is .nvmrc node 23, we are focused on this working in the environment that the programmer is in." MAIASS runs IN users' projects, so the runtime floor targets user environments, not internal dev.

Test plan

  • YAML validates (npx js-yaml).
  • Workflow structure: npm install -g maiassgit configgit checkout developBump versionSync package-lock.json.
  • npm install --package-lock-only brings the lockfile from 5.9.55 → 5.12.12.
  • npm test → 10/10 pass.
  • Local develop tip matches package.json 5.12.12 / engines.node >=20.

Out of scope

  • Template at templates/ci/github-version-bump.yml is NOT updated. Other projects using the template may not have a package-lock.json (PHP, Python, etc.) — the sync step would be a no-op or error there. Could file a follow-up for an "optional lockfile sync" template variant.

Ticket: https://velvary.atlassian.net/browse/MAI-42

Tyler Durton added 3 commits May 14, 2026 05:44
The auto-version-bump workflow runs `maiass -a patch` which rewrites
package.json's version field but doesn't run npm install. The lockfile
therefore lags by one version on every release. Six recent PRs hit
this drift and reverted the catch-up rather than expand their scope
(MAI-17, MAI-21, MAI-28, MAI-39, MAI-43, MAI-46) — the drift had
accumulated to package.json 5.12.12 vs package-lock 5.9.55.

Two changes in this PR (per MAI-42 decisions):

1. Add a "Sync package-lock.json" step to
   .github/workflows/version-bump.yml that runs after `maiass -a patch`.
   It pulls the bumped commit, runs `npm install --package-lock-only`
   (no node_modules install — we don't need them in this job), then
   commits and pushes the lockfile delta if there is one. This keeps
   the lockfile in sync forever.

2. One-time catchup: regenerate the lockfile to 5.12.12 using the same
   `--package-lock-only` invocation the workflow will use. No actual
   dependency tree changes — just the version field plus a small
   normalisation diff. engines.node is already at >=20 in package.json
   (target Node 20 LTS — user environments, not our dev env at .nvmrc
   Node 23).

Future workflow runs will pick up where this left off and the drift
problem is eliminated.

https://velvary.atlassian.net/browse/MAI-42
Code-review-by-CI: the first attempt used `npm install --package-lock-only`
which is faster but omits platform-specific optional transitive deps
(@emnapi/core, @emnapi/runtime in this case). `npm ci` in the test
matrix then refused to install because the lockfile didn't match what
package.json said should be there.

Switch both the workflow step AND the one-time catchup to a full
`npm install --no-audit --no-fund --ignore-scripts`:

- `--ignore-scripts` skips lifecycle scripts (we don't need any
  preinstall/postinstall side effects in this job).
- `--no-audit --no-fund` cuts the npm registry chatter.
- Full install (vs --package-lock-only) ensures `npm ci` compatibility.

Adds ~25s to each auto-bump run in CI — acceptable for correctness.

Verified locally: `npm ci --dry-run` now passes against the regenerated
lockfile.

https://velvary.atlassian.net/browse/MAI-42
CI's `npm ci` rejected my locally-regenerated lockfile because Mac
resolves @emnapi/* (platform-conditional optional transitive deps)
differently from Linux. The lockfile I wrote on macOS was missing
entries that Linux CI requires.

The workflow's new sync step runs on Linux GitHub Actions and will
produce the right lockfile organically on first execution. Reverting
the catchup commit; ship only the workflow change. Develop's existing
lockfile (5.9.55) still passes `npm ci` against the current
package.json because no deps were added between 5.9.55 and 5.12.12.

https://velvary.atlassian.net/browse/MAI-42
@vsmash vsmash merged commit 07a9749 into develop May 13, 2026
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant