Skip to content

Fix npm release lockfile #293

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
ludfjig merged 1 commit into from
Sep 3, 2026
Merged

Fix npm release lockfile #293

Show file tree
Hide file tree
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: 4 additions & 14 deletions Justfile
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -208,13 +208,8 @@ _test-native-modules-restore target=default-target:
# old version — which then fails the native_modules `--locked` build. These two
# recipes keep them in lockstep.

# Bump the version of EVERYTHING in lockstep so a release PR can't end up in a
# half-bumped, CI-breaking state. In one step this updates:
# * all workspace crates + the root Cargo.lock (via cargo-edit)
# * the excluded extended_runtime fixture's own Cargo.lock (cargo can't reach it)
# * the npm main package, the 3 platform packages, and their optionalDependencies
# * the npm package-lock.json (regenerated; the not-yet-published platform
# optionals are omitted, matching CI's `npm ci --omit=optional`)
# Bump all crate and npm package versions together.
# The publish workflow updates optionalDependencies to the release version.
Comment thread
jsturtevant marked this conversation as resolved.
# Requires cargo-edit (`cargo install cargo-edit`). ALWAYS use this instead of a
# bare `cargo set-version` / `npm version` when preparing a release.
set-version version:
Expand All @@ -228,13 +223,8 @@ set-version version:
cd src/js-host-api/npm/linux-x64-gnu && npm version {{ version }} --no-git-tag-version --allow-same-version --ignore-scripts
cd src/js-host-api/npm/linux-x64-musl && npm version {{ version }} --no-git-tag-version --allow-same-version --ignore-scripts
cd src/js-host-api/npm/win32-x64-msvc && npm version {{ version }} --no-git-tag-version --allow-same-version --ignore-scripts
# npm: point the main package's optionalDependencies at the new version
cd src/js-host-api && npm pkg set \
"optionalDependencies.@hyperlight-dev/js-host-api-linux-x64-gnu={{ version }}" \
"optionalDependencies.@hyperlight-dev/js-host-api-linux-x64-musl={{ version }}" \
"optionalDependencies.@hyperlight-dev/js-host-api-win32-x64-msvc={{ version }}"
# npm: regenerate package-lock.json so `npm ci --omit=optional` stays in sync
cd src/js-host-api && npm install --package-lock-only --omit=optional --ignore-scripts
# Verify the npm lockfile
cd src/js-host-api && npm ci --dry-run --omit=optional --ignore-scripts

# Fail fast if the excluded fixture lock has drifted from the workspace version.
# Without this, drift only surfaces as a cryptic poisoned-LazyLock panic inside
Expand Down
9 changes: 6 additions & 3 deletions docs/release.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,8 +10,11 @@ Do this with the `just set-version` recipe. **Always use this instead of bumping

- every workspace crate's `version` and the root `Cargo.lock`,
- the excluded `extended_runtime` fixture's own `Cargo.lock` (a bare `cargo set-version` can't reach it, and a stale one fails the `native_modules --locked` build),
- the npm main package, the three platform packages, and their `optionalDependencies`,
- `src/js-host-api/package-lock.json` (a stale one fails `npm ci` in the publish job).
- the npm main package and the three platform packages,
- the root package version in `src/js-host-api/package-lock.json`.

Keep `optionalDependencies` on the latest published version so `npm ci` can use
the lockfile. The release workflow updates them before publishing.

It uses `cargo set-version` from the `cargo-edit` crate under the hood, so install that first:

Expand All @@ -29,7 +32,7 @@ We keep the version number consistent across all crates and npm packages in the

Create a PR with these changes and merge it into the `main` branch.

> **Note:** The `CreateRelease` workflow *also* sets the npm packages to the tag's version at publish time (via `npm version`), so the published artifacts always match the tag regardless. Bumping them in the repo with `just set-version` is what keeps `npm ci` from failing *during* the release — don't skip it.
> **Note:** The release workflow sets all npm versions from the tag before publishing.

## Create a tag

Expand Down
60 changes: 57 additions & 3 deletions src/js-host-api/package-lock.json
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

6 changes: 3 additions & 3 deletions src/js-host-api/package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -35,9 +35,9 @@
},
"license": "Apache-2.0",
"optionalDependencies": {
"@hyperlight-dev/js-host-api-linux-x64-gnu": "0.4.0",
"@hyperlight-dev/js-host-api-linux-x64-musl": "0.4.0",
"@hyperlight-dev/js-host-api-win32-x64-msvc": "0.4.0"
"@hyperlight-dev/js-host-api-linux-x64-gnu": "0.3.3",
"@hyperlight-dev/js-host-api-linux-x64-musl": "0.3.3",
"@hyperlight-dev/js-host-api-win32-x64-msvc": "0.3.3"
},
"devDependencies": {
"@eslint/js": "^10.0.1",
Expand Down