Ship the host CLI as an npm dev dependency

Products built on truAPI are TypeScript and JavaScript apps, and for them the signing host is a dev server. It is the thing you start alongside vite to work against something real. Every other dev server in that world arrives as pnpm add -D and a lockfile entry.

truapi-host does not. Getting it means cargo install --git, which means a Rust toolchain and a three-minute build before a product author can run their own app against a real host. That is a large ask of someone whose project has no Rust in it, and it lands on them at the worst possible moment, the first five minutes.

We would like to install it the way we install vite:

pnpm add -D <the package>
pnpm exec truapi-host signing-host ...

The binary is not the whole gap

Three things sit between a JS product and a working local host, and we had to build all three ourselves. The first is the install above. The other two are code that every product will write the same way:

A way to start it and know when it is ready. --serve made this possible and prints a ready line, so wrapping it is small, but it is still ours to write and to keep matching the CLI's output.

A browser transport, which is the awkward one. The CLI serves product frames as one binary WebSocket message per SCALE frame. @parity/truapi's sandbox bootstrap speaks that frame format but only over two transports: the iframe truapi-init handover, and a MessagePort on window.__HOST_API_PORT__. There is no WebSocket transport, so a browser tab cannot reach the CLI without a pipe in between. Ours is 89 lines of MessageChannel pumped into the socket, and it is entirely mechanical: nothing in it is specific to our product, and any product doing this will land on the same thing.

Whether that belongs in a dev-host package or as a transport in the client is your call. We only want to stop being the ones who own it.

Why it is worth doing beyond convenience

It would also fix version skew, which is invisible today and which we hit twice this week.

The host and the product's @parity/truapi client have to agree on the SCALE wire. When they do not, the failure does not point at the cause: a pre-0.6 host against a current client fails every getAccount with MalformedFrame naming ProductAccountId::derivation_index. Our dev script carries a six-line comment warning about exactly this, because the only defence is remembering.

Nothing on a machine records which host it has. truapi-host --version is not accepted, and a binary built from a branch is indistinguishable from one built from main. We currently have an 0.7 client and an 0.9 client across two branches of one repo, and two different host builds, with no way to state which pairing was tested.

As a dev dependency the host sits in the lockfile next to the client it has to match, and the pairing stops being something people carry in their heads.

Name

Our preference is truapi-dev-host, unscoped. Short to type under pnpm exec, and it says what it is.

Worth avoiding: @parity/truapi-host is already an npm package and is the WASM host runtime, so anything reusing that stem invites people to install the wrong one. We have had to write a warning into our own docs telling people not to.

truapi unscoped belongs to an unrelated load-testing tool. truapi-dev-host, truapi-host-dev and truapi-dev are all free.