Stream: general

Topic: Component Model Dev Exp

view this post on Zulip Francisco López (Sep 08 2025 at 18:24):

Hey there! I'm new here,

I have been wanting to start poking around wasm and wasm component model for a while, I believe the potential is huge and love what you folks are doing. I've read about the tech, I'm familiar with it but I have not practical experience beyond a few hello words in wasm and not at all with components. I do have experience with Rust. I hope my questions and noob eyes help improving the experience for fellow newcomers to the ecosystem and also as a somewhat reference. Sorry if my questions have already been answered, I couldn't find them.

I want to go deep into the ecosystem, my general approach to that is to start an ambitious project that forces me to understand how things really work. My hobby project is about building a platform to allow developers produce software in any language they like and consume software in any other language they don't like but that is available to them. WASM/WASI and Components are perfect for that.

Now, I've started with the calculator tutorial. But the moment I go out of the tutorial I have a hard time understanding how to do things and there seem to be multiple ways of doing them. It all seems to go down the package manager/building experience.

My follow-up calculator step is:

Building my first WASM Component

Building Calculate in Typescript and publish it with wasn't easy. jco kept failing and still does with:

(jco componentize) Error: Failed to initialize component:
Exception while evaluating top-level script
ReferenceError: Error loading module "./simple-calculator.js" (resolved path "simple-calculator.js"): No such file or directory

I had to write my own script using componentize-js. That worked, then I was surprised I needed to publish both the wit and wasm modules to my local registry using wkg. Is there a way where wkg can manage the whole component? I'm looking for a similar experience to that of cargo/npm.

Package Manager

Installing deps

I've gotten to know that wkg is the 'package manager?', took me a while to get it to work. I would admit here skill issue and LLM added confusion. Looks like LLMs are yet to learn a lot more about WIT syntax.

When running it in my add component, I see it pulls many wit files, including my calculate one. It may be I had the wrong expectations but I was expecting it to:

First question, how do I make the wasm component available?

Building add component

When building a component that depends on another one, things got interesting. My rust bindings aren't working, initially they were pointing to my wit/add.wit but I needed to change them to just wit so it could find the deps and include generate_all. Funny it worked for rust-analyzer but when running cargo component build it doesn't work, can't find my package calculate.

1: package 'my:calculate@1.0.0' not found. known packages:
           example:rust-component@1.0.0

It is not clear to me, in order to use a dependency fetched with wkg if I need to specify the path manually or not in my Cargo.toml file. Turns out it is not, but I do need to specify the dep like this.

[package.metadata.component.target.dependencies]
"my:calculate" = "1.0.0"

This behavior may be different from typescript importing, as I haven't imported anything in a ts project yet. I do see a wkg.lock though so. Are all wasm deps meant to be managed through the wkg.lock/toml configurations? Is the Cargo.toml going away? What is the unification plan there?

Running a component

Running a component is hard when you're composing stuff. Also the composition work is exposed to the user (unless I'm missing some CLI tool or command that does it for you). I need to make sure I compose all the wasm modules into a single one using wac (another CLI, one of the major sources of confusion for me, the many different CLIs there are). So I got to componse my two modules, add and calculate. Great, now it fails with some other missing stuff:

Error: failed to run main module `composed.wasm`

Caused by:
    0: component imports instance `wasi:http/types@0.2.3`, but a matching implementation was not found in the linker
    1: instance export `fields` has the wrong type
    2: resource implementation is missing

I guess I could remove these deps since I'm not really using them but that would just postpone this problem for future more advanced tests I had planned. So I'm wondering, how do I manage this?

Is there a future planned (or already exists) where I can do, I'm gonna create yet another hypothetical CLI:

Where those commands manage the deps installation and composition. I get the main difficulty lies around the different languages behavior but, are there plans to converge? At the end, the languages would need their bindings for imported wasm components (should be handled by wasm fetch IMO) and the build process, wasm can forward that build to the language tooling and then finish up with the composition (or allowing to skip composition in favor of dynamic linking by the runtime).

I see many wasm platforms shine on this, probably part of the value added and why the foundational tooling is not there but, for me, not looking into any platform this fragmentation is the main barrier to the ecosystem I'm facing right now. Maybe I'm looking into old tools/docs. Please would appreciate some guidance into what's the common/main way of achieving this with low friction and ease of use.

Again, thank you for this. It's really pushing software towards what I believe should be.

view this post on Zulip Lann Martin (Sep 08 2025 at 18:50):

Be aware that cargo component has been deprecated in favor of the Rust wasm32-wasip2 target. There is ongoing work to rewrite relevant documentation.

view this post on Zulip Lann Martin (Sep 08 2025 at 18:52):

As you have noticed, LLMs have not slurped up enough data on component model spec or tooling to be useful. I'd suggest mostly avoiding the use of LLMs in this area for now.

view this post on Zulip Francisco López (Sep 08 2025 at 18:55):

Lann Martin said:

As you have noticed, LLMs have not slurped up enough data on component model spec or tooling to be useful. I'd suggest mostly avoiding the use of LLMs in this area for now.

yep, they got me into a few rabbit holes that made it all more difficult. It's been the first thing I'm learning in a while and I hoped to also try LLMs in the process of helping learn new concepts and tools but it backfired :)

view this post on Zulip Alex Crichton (Sep 08 2025 at 22:55):

Thanks for writing this all up! The way I would personally phrase it is that we've been spending a lot of energy and work on simply getting a single component to run, much less a composed one. Everything we do to make a single component better in the long run makes the compositional story (what you're looking for here) better as well.

It's going to take a lot of work and design to get to the future you're describing, and a lot of us share a similar vision and desire to get there. Given how aspirational it is, though, it's going to take time and manpower which are limited resources and are currently allocated elsewhere

Last updated: Dec 06 2025 at 05:03 UTC