Summary
Installing any component built with the published JS packages fails on astrid 0.9.1 and 0.9.4 with:
lifecycle dispatch failed: Unsupported entry point: Failed to instantiate WASM
component for lifecycle: component imports instance `astrid:process/host@1.0.0`,
but a matching implementation was not found in the linker
@unicity-astrid/build 0.1.0 synthesizes a world that imports astrid:process/host@1.0.0, and the SDK bridge imports the specifier unconditionally (esbuild keeps it — every JS capsule links every SDK module whether used or not). Kernels ≥ 0.9.1 register process@1.1.0 but no longer register a 1.0.0 implementation in the lifecycle linker, so every stock JS capsule is uninstallable on current kernels.
The astrid:process/host@1.0.0 string is still present in the binary, which suggests an unintended registration gap rather than a deliberate removal.
Reproduction
npm i @unicity-astrid/sdk@0.1.0 @unicity-astrid/build@0.1.0
- Build any capsule (even a no-op
@install that just logs).
astrid capsule install . → the error above.
Impact
The published JS SDK/build toolchain produces no installable artifact on released kernels; JS capsule authors are blocked at step one.
Workaround we used
Drop the import on both sides — stub spawn / spawnBackground in sdk/dist/process.js, and remove import astrid:process/host@1.0.0; from the world template in build/src/index.mjs. Our capsule never spawns processes (the SDK documents astrid:process as optional per target). The component shrank 13.10 MB / 170 host imports → 12.30 MB / 142 and then installed and ran verified sessions on 0.9.4.
Suggested fix (any one)
- Re-register the
1.0.0 shim in the lifecycle linker, or
- Publish SDK/build packages targeting the current WITs, or
- Make the build tree-shake host domains the capsule does not use.
Environment
@unicity-astrid/sdk 0.1.0, @unicity-astrid/build 0.1.0 (npm)
- astrid 0.9.1 and 0.9.4 release binaries, x86_64-unknown-linux-gnu
- Ubuntu 24.04 (WSL2), Node 22
- Capsule: TypeScript, standard TC39 decorators (
experimentalDecorators: false, ES2022) → astrid-js-build → ComponentizeJS → wasm32-wasip2
Part of a small batch of findings from building a non-trivial JS capsule. Related: #20 (decorator registry read before construction). A minimal reproducing repo and the exact patch set are available on request.
Summary
Installing any component built with the published JS packages fails on astrid 0.9.1 and 0.9.4 with:
@unicity-astrid/build0.1.0 synthesizes a world that importsastrid:process/host@1.0.0, and the SDK bridge imports the specifier unconditionally (esbuild keeps it — every JS capsule links every SDK module whether used or not). Kernels ≥ 0.9.1 registerprocess@1.1.0but no longer register a1.0.0implementation in the lifecycle linker, so every stock JS capsule is uninstallable on current kernels.The
astrid:process/host@1.0.0string is still present in the binary, which suggests an unintended registration gap rather than a deliberate removal.Reproduction
npm i @unicity-astrid/sdk@0.1.0 @unicity-astrid/build@0.1.0@installthat just logs).astrid capsule install .→ the error above.Impact
The published JS SDK/build toolchain produces no installable artifact on released kernels; JS capsule authors are blocked at step one.
Workaround we used
Drop the import on both sides — stub
spawn/spawnBackgroundinsdk/dist/process.js, and removeimport astrid:process/host@1.0.0;from the world template inbuild/src/index.mjs. Our capsule never spawns processes (the SDK documentsastrid:processas optional per target). The component shrank 13.10 MB / 170 host imports → 12.30 MB / 142 and then installed and ran verified sessions on 0.9.4.Suggested fix (any one)
1.0.0shim in the lifecycle linker, orEnvironment
@unicity-astrid/sdk0.1.0,@unicity-astrid/build0.1.0 (npm)experimentalDecorators: false, ES2022) →astrid-js-build→ ComponentizeJS → wasm32-wasip2Part of a small batch of findings from building a non-trivial JS capsule. Related: #20 (decorator registry read before construction). A minimal reproducing repo and the exact patch set are available on request.