fix(zed-extension): auto-download platform-specific streamd binary

kfickel commented

2026-08-06 17:48:08 +02:00

Owner

Summary

Fixes #127. The Zed extension's language_server_command previously returned a bare "streamd" command (or shelled out to wsl streamd lsp on Windows), assuming a binary was already reachable. Under Zed Remote Development, Zed resolves that command relative to the extension's private work directory, which was never populated, so the LSP failed with No such file or directory.

language_server_command now prefers an existing streamd on PATH (Worktree::which), otherwise downloads the matching platform release asset (linux-x86_64 / windows-x86_64) into the extension's own work directory, caches it by version-embedded filename, and returns an absolute path.
macOS and non-x86_64 platforms (no prebuilt binary exists) get a clear, friendly error via set_language_server_installation_status/Result::Err instead of a silent failure.
The WSL-shelling Windows branch is removed entirely — local Windows Zed now runs the native .exe directly, and Remote Development (WSL/SSH) already executes the extension inside the remote host.
flake.nix's mkZedExtension now stamps the real streamd version (read from the same root Cargo.toml every other package already uses) into both the compiled wasm (via STREAMD_VERSION, consumed with option_env!) and extension.toml, fixing a previously hardcoded, never-bumped version = "0.0.1".
README's Zed extension section rewritten to describe the new auto-download behavior and drop the WSL2-only framing.

No configurable path setting or checksum verification was added — scoped out during refinement (see the plan comment on #127); Worktree::which already covers self-managed installs, and downloads come straight from this project's own Forgejo instance over HTTPS.

Test plan

cargo test — 5 new unit tests for release_asset_name (Linux/Windows/macOS/unsupported-arch) pass
cargo clippy --all-targets -- -D warnings clean
cargo fmt --check clean
nix build .#zed-extension — confirmed extension.toml's version is patched to match root Cargo.toml (not 0.0.1)
strings on the built extension.wasm confirms STREAMD_VERSION and both platform asset-name format strings are correctly baked in
nix build .#zed-extension-zip — produces streamd-zed-extension-<version>.zip as before
nix flake check — all checks pass (clippy, fmt, test, pre-commit)
Manual: install as a dev extension and verify the download path and cache behavior in a real Zed session (not done in this environment — no Zed instance available)
Manual: verify against the actual Remote Development regression (WSL2/SSH remote) described in #127

## Summary Fixes #127. The Zed extension's `language_server_command` previously returned a bare `"streamd"` command (or shelled out to `wsl streamd lsp` on Windows), assuming a binary was already reachable. Under Zed Remote Development, Zed resolves that command relative to the extension's private work directory, which was never populated, so the LSP failed with `No such file or directory`. - `language_server_command` now prefers an existing `streamd` on `PATH` (`Worktree::which`), otherwise downloads the matching platform release asset (`linux-x86_64` / `windows-x86_64`) into the extension's own work directory, caches it by version-embedded filename, and returns an absolute path. - macOS and non-x86_64 platforms (no prebuilt binary exists) get a clear, friendly error via `set_language_server_installation_status`/`Result::Err` instead of a silent failure. - The WSL-shelling Windows branch is removed entirely — local Windows Zed now runs the native `.exe` directly, and Remote Development (WSL/SSH) already executes the extension inside the remote host. - `flake.nix`'s `mkZedExtension` now stamps the real `streamd` version (read from the same root `Cargo.toml` every other package already uses) into both the compiled wasm (via `STREAMD_VERSION`, consumed with `option_env!`) and `extension.toml`, fixing a previously hardcoded, never-bumped `version = "0.0.1"`. - README's Zed extension section rewritten to describe the new auto-download behavior and drop the WSL2-only framing. No configurable path setting or checksum verification was added — scoped out during refinement (see the plan comment on #127); `Worktree::which` already covers self-managed installs, and downloads come straight from this project's own Forgejo instance over HTTPS. ## Test plan - [x] `cargo test` — 5 new unit tests for `release_asset_name` (Linux/Windows/macOS/unsupported-arch) pass - [x] `cargo clippy --all-targets -- -D warnings` clean - [x] `cargo fmt --check` clean - [x] `nix build .#zed-extension` — confirmed `extension.toml`'s version is patched to match root `Cargo.toml` (not `0.0.1`) - [x] `strings` on the built `extension.wasm` confirms `STREAMD_VERSION` and both platform asset-name format strings are correctly baked in - [x] `nix build .#zed-extension-zip` — produces `streamd-zed-extension-<version>.zip` as before - [x] `nix flake check` — all checks pass (clippy, fmt, test, pre-commit) - [ ] Manual: install as a dev extension and verify the download path and cache behavior in a real Zed session (not done in this environment — no Zed instance available) - [ ] Manual: verify against the actual Remote Development regression (WSL2/SSH remote) described in #127

kfickel added 3 commits

2026-08-06 17:48:08 +02:00

fix(zed-extension): auto-download platform-specific streamd binary 56876d37bc

The extension previously returned a bare "streamd" command (or shelled
out to `wsl streamd lsp` on Windows), assuming a binary was already
reachable. Under Zed Remote Development, Zed resolves that command
relative to the extension's private work directory, which was never
populated, so the LSP failed to start.

language_server_command now:
- prefers an existing streamd on PATH via Worktree::which
- otherwise downloads the matching platform release asset
  (linux-x86_64 / windows-x86_64) into the extension's work directory,
  caching by version-embedded filename
- returns a clear error for macOS/non-x86_64, which have no prebuilt
  binary yet
- removes the WSL-shelling Windows branch entirely

Fixes #127

build(zed-extension): stamp real version into wasm build and extension.toml 9e14bd289f

mkZedExtension previously hardcoded version = "0.0.1" and never touched
the checked-in extension.toml placeholder, so the shipped extension
never reflected the actual streamd release it was built alongside.

Now the derivation reuses the same root-Cargo.toml-derived `version`
binding every other package already uses, exports it as STREAMD_VERSION
so the wasm build can bake it in via option_env!, and patches
extension.toml's version field to match at build time.

docs: update Zed extension section for auto-download behavior

Continuous Integration / Lint, Check & Test (push) Successful in 4m21s

Details

Continuous Integration / Build Package (push) Successful in 5m36s

Details

bd73bf3c9a

The extension no longer requires manually installing streamd inside
WSL2 first, and now works for local Windows/Linux Zed and Remote
Development generally, not just WSL2. Documents the on-PATH/download
resolution order and the current macOS/non-x86_64 limitation.

kfickel referenced this pull request

2026-08-06 17:49:01 +02:00

Zed remote extension fails to start streamd because no binary is installed #127

kfickel added 1 commit

2026-08-06 17:54:28 +02:00

chore(build): bump version to 0.2.7

Continuous Integration / Build Package (push) Successful in 7s

Details

Continuous Integration / Lint, Check & Test (push) Successful in 29s

Details

Release / Build and Release (push) Successful in 7m0s

Details