Spec prefix: SWR-ARCH-*
Status: Draft
Shipwright provides shared libraries and tooling for deploying binaries and IDE extensions. The libraries use generic public package names and are designed for any team shipping language servers, MCP servers, sidecars, or CLI tools alongside IDE extensions.
Product repos stop maintaining bespoke version parsers, platform directory conventions, package manifests, and startup checks. Instead they adopt Shipwright and get consistent behavior across all host environments.
shipwright
- Adds a standard
--versionimplementation for Rust binaries. - Exposes plain text and JSON version metadata.
- Reads
CARGO_PKG_NAME,CARGO_PKG_VERSION, target triple, and optional build metadata.
shipwright-manifest
- Defines the
shipwright.jsonproduct manifest data model. - Validates component ids, versions, platform names, checksums, and required flags.
- Generates target-specific asset names.
shipwright-host
- Pure binary-resolution algorithm for IDE extension hosts.
- No I/O — the version-probe function is injected by the caller.
- Every resolver port must pass
schemas/test-vectors.json.
shipwright-zed
- Zed editor host integration built on
shipwright-host.
@nimblesite/shipwright-vscode
- Loads
shipwright.jsonfrom a VS Code extension. - Resolves binaries using only the sources declared in the product's
shipwright.jsonmanifest. - Runs
--versionthroughexecFileorspawnwithout a shell. - Returns structured diagnostics and user-facing messages.
@nimblesite/shipwright-core
- Canonical path construction:
joinBinary,pathCandidate,envPath,executableName,exeSuffix,platformSeparator. All host packages (vscode, IntelliJ, Zed) MUST import these — never reimplement path joining. - Pure
resolve()algorithm: walks only the sources listed in the component'ssourcesarray with an injected probe callback. Products control their own cascade — e.g.["user-setting", "bundled"]for self-contained extensions that must never fall back to system binaries. - Platform ids, error types, and type definitions shared across all hosts.
@nimblesite/shipwright-mcp
- Adds
--versionhandling for npm/MCP binaries. - Generates MCP server
serverInfo.versionfrompackage.json. - Prevents hard-coded server versions drifting from package metadata.
@nimblesite/shipwright-validate-manifest
- AJV-backed CLI for validating
shipwright.jsonin product CI.
Shipwright (library)
- Adds
--versionhandling to .NET sidecars and global tools. - Reads package version from assembly metadata.
- Emits the same plain text and JSON contract as Rust and Node.
Shipwright (global tool — dotnet tool install -g Shipwright)
- CLI for validating manifests, verifying binaries, and inspecting packages.
shipwright
- Binary resolver and
--versioncontract helpers for Dart/Flutter applications.
shipwright-version-stamp
Stamps a semver tag into every manifest file in the repo with a single command:
shipwright-version-stamp --tag v1.2.3 --root .Supports: Cargo.toml, package.json, *.csproj, pubspec.yaml.
| Entity | Meaning |
|---|---|
| Product | A tool family with a stable id and version. |
| Component | A runtime executable or config payload required by a product. |
| Host | An IDE or runtime environment that resolves and launches components. |
| Resolver | Host-specific logic that locates and validates a component. |
| Verification | Version, checksum, platform, and protocol checks before startup or release. |
The manifest supports native binaries, .NET tools, Node binaries, WASM/Zed extension libraries, config payloads, and helper executables.
Product repos integrate in this order:
- Add
shipwright(or the appropriate language library) to every binary and sidecar. - Add
shipwright.jsonto each package. - Replace local editor resolver code with the appropriate host library.
- Update release packaging to place binaries under standard
bin/<platform>directories. - Add CI checks that validate the manifest and verify binaries.
- The manifest schema is versioned via
manifestVersion. - Host libraries must reject incompatible newer manifest schemas.
- Host libraries may warn on older compatible schemas.
- Component kinds are extensible — new host types can be added without breaking existing fields.