jco componentize error on a relative source import · jco

I want to componentize a node js "bin" as a cli/command component. I seem to be mixed up on how to achieve this. Do I need to bundle all imports into one script and jco componentize that or are import {myApi} from './poultry.js' allowed and it is for some reason not working for me?

This seems to be an error stating that I can't import from relative sources while componentizing?

pnpm exec jco componentize --wit wasm/poultry.wit lib_js/bin.js -o poultry.wasm
(jco componentize) Error: Failed to initialize component:
Exception while evaluating top-level script
ReferenceError: Error loading module "./poultry.js" (resolved path "poultry.js"): No such file or directory

I'm also curious, is it necessary to create an arbitrary WIT that exports "cli/command" or could that be implicit because the entrypoint has an exported "run()" function, much like how the Rust target wasm32-wasip2 will automatically build a cli/command component from a binary crate?

Milan (rajsite) (Nov 24 2025 at 17:05):

Resolving Node.js packages · Issue #15 · bytecodealliance/StarlingMonkey

I really like the static nature of source resolution during Wizering as an alternative to bundling. Further to this, it could be worth implementing the full Node.js resolution algorithm to automati...

jco/examples/components/http-server-hono at main · bytecodealliance/jco

JavaScript toolchain for working with WebAssembly Components - bytecodealliance/jco

adam (Nov 25 2025 at 00:55):

Are there plans to have a frontend for jco or componentize that is more like the dx of building WASI components with the Rust tooling? Seems like a huge difference between the JS experience and Rust.

Having started with the Rust experience, it caught me off guard that building a cli/command component without any component imports and no other exports would even need a wit file.

Milan (rajsite) (Nov 25 2025 at 05:54):

Support pulling known WASI WIT worlds from BCA repositories · Issue #529 · bytecodealliance/jco

Now that BCA tooling (wkg, etc) have evolved to be be able to push/pull OCI artifacts for well known/standardized interfaces from a central location, it would be useful if jco could make use of the...

Node.js builtins · Issue #188 · bytecodealliance/StarlingMonkey

Tracking issue for supporting Node.js builtins (import fs from node:fs, ...), where each builtin can be individually turned on or off. We should implement this layer in C++ (or Rust), and try to bu...

adam (Nov 25 2025 at 21:06):

So I looked at the docs for the componentiz from @bytecodealliance/componentize-js and it explicitly says

     and can import other modules using relative paths.
   */
  sourcePath: string;

I tried this API as an alternative to using jco from the CLI but when using this fn, it throws an error on any "node:" style imports:

ReferenceError: Error loading module "node:fs/promises" (resolved path "lib_js/node:fs/promises"): No such file or directory

import { componentize } from '@bytecodealliance/componentize-js'

const { component } = await componentize({
    sourcePath: 'lib_js/bin.js',
    witPath: 'wasm/poultry.wit',
    preview2Adapter: 'node_modules/@bytecodealliance/jco/lib/wasi_snapshot_preview1.command.wasm',
})

console.log(new TextDecoder().decode(component))

It sounds like I don't need to use esbuild to prebundle with the most uptodate componentize, but node dependencies seem to cause an error.

adam (Nov 25 2025 at 21:09):

I'm also confused about the path to preview 2 adapter option. JCO uses a path to a file packaged with the npm package that's called preview1.

adam (Nov 25 2025 at 21:19):

It sounds like I don't need to use esbuild to prebundle with the most up-to-date componentize, but node dependencies seem to cause an error. However, if I use JCO which uses the newest componentize API, I get errors from relative path imports. Head scratch fever!

adam (Nov 25 2025 at 21:38):

The preview2-shim npm package seems to have WASI impls for Node and browser environments, yet a suggestion I found for making a JS component from a Node JS program is to implement the component using import XYZ from 'ABC' where ABC is a WASI import specifier and when hosting the component needing to fulfill the FS APIs with those customized imports.

Milan (rajsite) (Nov 25 2025 at 23:30):

The shim package has implementations of wasi:fs -> js. So that's taking any wasm component (rust, go, js-based) that uses wasi:fs and generates a browser / node library for it (js + core wasm) to translate wasi:fs calls into other calls (browser custom API and node via fs).

I'm not aware of any implementations of node:fs -> js backed by wasi:fs (taking js that call node:fs and transforms to a component via JCO / ComponentizeJS that calls wasi:fs).

The second issue I had linked before was for first class node builtins (like node:fs) in starlingmonkey. So far we have first class support for math, date, webcrypto, fetch, fetch- event, backed by wasi apis but not node:fs.

Another related project is jco-std, that provides an alternative to native fetch-event via express like APIs backed by wasi:http. That would be a good place to land node:fs like APIs backed by wasi:fs. https://github.com/bytecodealliance/jco/tree/main/packages/jco-std

But also I'm just a lurker, wasn't aware of the relative import support in ComponentizeJS so maybe others are aware of node:fs implementations backed by wasi:fs. I'd love that too! The alternative right now is using wasi:fs directly which isn't so bad but would certainly appreciate a more familiar API.

jco/packages/jco-std at main · bytecodealliance/jco

JavaScript toolchain for working with WebAssembly Components - bytecodealliance/jco

Victor Adossi (Nov 26 2025 at 07:42):

Thanks for the excellent support/help here Milan! Just chiming in to note that everything Milan is saying is spot on at this point!

I think Jco could be behind on componentize-js versions (IIRC it's not but I could be wrong!)

Right now, we don't have a Node shim but we absolutely could and it's something we want to do. Like Milan said ideally we'd have first class builtins at the StarlingMonkey level, but right now what is supported is more like WinterCG/WinterTC (i.e. interoperable Javascript runtime features)

Victor Adossi (Nov 26 2025 at 07:44):

Just between you me and everyone else that could possibly be reading this thread, as soon as async work in Jco is done I'm looking forward to adding TS support and bundling via rolldown -- the oxc ecosystem is fantastic and fits right in.

Along with that it would be natural to add a NodeJS shim via a project like unenv , even if it would be slow (and maybe have the integrations themselves live in jco-std and be re-surfaced in Jco).

This is all really exciting work (I think) and I'm happy to review any PRs that move us forward! Even taking on "little" stuff like moving the current projects to Typescript would be much appreciated.

Stream: jco

Topic: jco componentize error on a relative source import

adam (Nov 24 2025 at 00:18):