chore: release 0.3.0 with idx-mcp

Bump the workspace and npm packages to 0.3.0. The release workflow
builds and attaches idx-mcp binaries next to idx, the npm launcher and
installer pick their binary from package.json so npm/idx-mcp reuses
them, and the npm smoke test covers both packages.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
hermes 2026-10-14 19:01:29 +00:00
commit 8e3323e4f7
15 changed files with 186 additions and 92 deletions

View file

@ -1,6 +1,10 @@
# npm distribution
The npm package `idx-cli` is a small wrapper around the native `idx` binary.
The npm packages `idx-cli` (repo root) and `idx-mcp` (`npm/idx-mcp/`) are small
wrappers around the native `idx` and `idx-mcp` binaries. Both use the same
launcher and installer from `scripts/`; the package's `nativeBinary` field
picks the binary, and `npm/idx-mcp` copies the scripts in at `prepack`.
The `idx-cli` package
The package keeps the JavaScript launcher and postinstall downloader. The
downloader selects a prebuilt GitHub Release asset for the current platform and
places it at the path used by the `idx` bin entry.
@ -14,6 +18,9 @@ Supported release assets:
| macOS arm64 | `aarch64-apple-darwin` | `idx-darwin-arm64` |
| macOS x64 | `x86_64-apple-darwin` | `idx-darwin-x64` |
`idx-mcp` assets use the same platforms with an `idx-mcp-` prefix, for
example `idx-mcp-linux-x64`.
The Linux binaries are statically linked against musl, so they do not depend
on the host glibc version.
@ -31,7 +38,7 @@ npx idx-cli --help
```
The package version and the release tag must match. For example, package
version `0.2.4` downloads assets from the `v0.2.4` GitHub Release.
version `0.3.0` downloads assets from the `v0.3.0` GitHub Release.
The postinstall script downloads `SHA256SUMS` from the same release and
refuses to install a binary whose checksum does not match.
@ -81,7 +88,7 @@ URLs must stay aligned with `scripts/install.js`.
To attach binaries to a tag that already exists, run the workflow manually:
```bash
gh workflow run release.yml -f tag=v0.2.4
gh workflow run release.yml -f tag=v0.3.0
```
Pull requests that touch the workflow or the installer run the build jobs
@ -89,9 +96,13 @@ without publishing, so target breakage shows up before a release.
Release order:
1. Push the tag, or run the workflow for an existing tag.
2. Confirm the release has all binaries plus `SHA256SUMS`.
3. Run `npm publish` from the tagged commit. The account has two-factor auth,
so npm asks for a browser approval or `--otp=<code>`. A version number
can never be republished, so bump `Cargo.toml` and `package.json` together
before tagging.
1. Bump the version together in `Cargo.toml` (workspace version and the
`idx-core` dependency pin), `package.json`, and `npm/idx-mcp/package.json`.
A version number can never be republished.
2. Push the tag, or run the workflow for an existing tag.
3. Publish the crates from the tagged commit, dependency first:
`cargo publish -p idx-core`, then `-p idx-cli` and `-p idx-mcp`.
4. Confirm the release has all eight binaries plus `SHA256SUMS`.
5. Run `npm publish` in the repo root and in `npm/idx-mcp/` from the tagged
commit. The account has two-factor auth, so npm asks for a browser
approval or `--otp=<code>`.