Ryan Hunt (Sep 15 2026 at 16:39): Ryan Hunt (Sep 15 2026 at 16:39):I talked with Thomas Lively about getting a new repo in the WebAssembly org. He was open to it, but pushed slightly back and asked why we can't just rename 'wasi-sdk'. I missed last weeks meeting, so I believe this was discussed more then and Alex strongly preferred not renaming it. Alex, what are your concerns again? I told Thomas I'd get back to him with more rationale.
That aside, there is the question of what to name the new repo. I wonder if it's possible to name the new repo to just 'component-sdk' and publish both new artifacts there. Then eventually when enough things are migrated, we could deprecate the 'wasi-sdk' repo. It feels like a nice goal to eventually have a single repo for all this code, and 'component' is generic enough to cover both.
I don't think 'web-sdk' would fly, it's too generic and we'd probably get pushback. 'web-component-sdk' collides with web components. So that would leave 'component-web-sdk' as a fallback.
@Alex Crichton @Ben Visness
Alex Crichton (Sep 15 2026 at 16:44):My main worry was basically the volume of locations that refer to "wasi" or "wasi-sdk" that have to be updated to something else when the wasi-sdk repo is archived/renamed/etc. Some examples are:
#include <wasi/version.h> which is the primary vector for conditional compilation based on wasi versions (e.g. __wasip{1,2,3}__)For myself this was then all capped off with the realization that this would sort of continue to perpetuate the feeling of instability for WASI and such.
Overall though I very much agree that the long-term goal should be one place to get clang & co. I do not want a long-term solution where there's both a wasi-sdk and component-web-sdk for example.
Alex Crichton (Sep 15 2026 at 16:45):tl;dr; I got cold feet and had second thoughts about renaming wasi-sdk
Alex Crichton (Sep 15 2026 at 16:45):Maintenance of wasi-sdk is also pretty onerous right now insofar as every PR has like ~6 hours of CI because windows is slow and refuses to ccache correctly.
Alex Crichton (Sep 15 2026 at 16:47):I'll definitely admit though that some of this is sort of selfish of me insofar as I suspect that a lot of the renaming work would fall on me and I'm not particularly eager to go do all that
Alex Crichton (Sep 15 2026 at 16:48):but also I mean none of what I bring up is like a super strong objection, and it's definitely technically feasible to rename
Ryan Hunt (Sep 15 2026 at 16:56):Sure I get that, not trying to add unreasonable work here, especially with all the stuff going on.
It sounds like eventually renaming things over makes sense, but it will just take a while. I wonder if instead of renaming the wasi-sdk repo, we could just create component-sdk as a mirror that automatically follows along with wasi-sdk. We could keep issues/PRs on wasi-sdk. Eventually when things are migrated over, we could switch from component-sdk being the mirror to being the development target. Or alternatively start with wasi-sdk being a mirror that is eventually disabled.
Ryan Hunt (Sep 15 2026 at 16:57):My concern is to avoid fragmenting development here. I think the web.wit work and other things are going to need to happen in the same repo as the wasi target.
Alex Crichton (Sep 15 2026 at 16:58):yeah IIRC that was the general conclusion, component-sdk would repackage wasi-sdk's artifacts (wasi-sdk would include wasm32-webp2) and would possibly include web.h and libweb.a or similar for a web-sdk-style-download
Alex Crichton (Sep 15 2026 at 16:58):we should probably talk more in depth this week about web.h to hammer out a more concrete plan there
Ryan Hunt (Sep 15 2026 at 16:59):Ah okay. I had heard an idea around having component-sdk embed wasi-sdk as a submodule. I think a true git mirror would be cleaner, because I'm not sure what would actually live in the repo besides just the submodule
Alex Crichton (Sep 15 2026 at 17:00):my rough assertion is that it's going to be best to not actually have parallel CI builds for anything since it takes so long to build everything
Alex Crichton (Sep 15 2026 at 17:00):there's no problem adding wasm32-webp2 of course to wasi-sdk, so the actual production of things is of no concern, it's basically around the optics and where things are downloaded
Alex Crichton (Sep 15 2026 at 17:00):that's where the thinking that (component-)web-sdk would repackage the wasi-sdk artifacts
Alex Crichton (Sep 15 2026 at 17:01):although this also touches on distribution of web.wit/web.h b/c I was thinking that wasi-sdk wouldn't ever want to include that
Alex Crichton (Sep 15 2026 at 17:01):another example was wasi-sdk not including bindings to wasi:http as an example
Ryan Hunt (Sep 15 2026 at 17:02):I guess it depends on how libc bootstraps some of its API's. I was imagining it'd need access to a small subset of things like console.log/etc. Definitely doesn't need many web API's. But a few
Alex Crichton (Sep 15 2026 at 17:03):yeah building wasi-libc needs WITs for sure, but right now those bindings are internal to wasi-libc and aren't published
Alex Crichton (Sep 15 2026 at 17:03):or, well, actually they are published, but not necessarily easily accessible
Alex Crichton (Sep 15 2026 at 17:03):so wasi-libc would include browser.wit and bind things like performance.now or w/e for sure, but web.h is like "ok but if you actually do web development use this"
Ryan Hunt (Sep 15 2026 at 17:04):Yeah that makes sense. In that case, web.h doesn't need to live with wasi-sdk/component-sdk. We probably could hand-craft a minimal web-libc.wit that has just the basics and include that there.
Alex Crichton (Sep 15 2026 at 17:05):partly this is where I think we should talk about web.h in more detail because personally I think it might make the most sense to not include that in a *-sdk download
Alex Crichton (Sep 15 2026 at 17:06):but this has a large impact on developer experience though so we'll definitely want to make an actual decision about this
Ben Visness (Sep 15 2026 at 17:07):I would consider web.h to be the equivalent of a web-sys crate for C/C++ developers and not part of the "toolchain". It could live in the same repo as toolchain things but shouldn't be part of a toolchain release imo.
Alex Crichton (Sep 15 2026 at 17:08):agreed yeah, although I'd be concerned about living in the toolchain repo insofar as CI for a toolchain is typically quite expensive whereas CI for web.h in theory should be pretty cheap
Ben Visness (Sep 15 2026 at 17:08):Depends on what triggers the CI, I guess?
Alex Crichton (Sep 15 2026 at 17:09):it's true, and I'm perhaps biased a bit here, but most repos I work on operate on the model of everything that merges runs the full CI of the repo to ensure nothing gets out of sync
Alex Crichton (Sep 15 2026 at 17:09):running a subset of CI checks makes sense for PRs IMO but when merging I personally don't trust filters much b/c they often miss subtle interactions
Alex Crichton (Sep 15 2026 at 17:10):but overall what I'm thinking is we should nail down web.h distribution, and that might re-shift things to biting the bullet and renaming wasi-sdk
Alex Crichton (Sep 15 2026 at 17:10):it also might not, iunno
Alex Crichton (Sep 15 2026 at 17:10):I suppose development & distribution of web.h
Ben Visness (Sep 15 2026 at 17:13):I'm just torn between the idea of having a separate repo for browser.wit / web.h / other bindings artifacts (?) that can move at their own pace, and the idea of having a one-stop shop for the whole affair (incl. a natural place to centralize issues, since I imagine many might be cross-cutting)
Alex Crichton (Sep 15 2026 at 17:15):Along those lines the issue trackers of wasilibc and wasisdk are quite blurred yeah and not great being separate
Ben Visness (Sep 15 2026 at 17:16):It might also be important to consider how interlinked web.h / web.a / etc. will be with the actual clang toolchains. If they need to remain in sync, then it might be best to release them together (sometimes releasing smaller updates to just web.h)
Alex Crichton (Sep 15 2026 at 17:19):If web.h were a separate repo, I'd personally say that the produced artifact should be *.{h,c} files (maybe *.{hh,cc} too) rather than *.a, and that should keep compat pretty orthgonal b/c then users don't have to align targets or we have to deal with abis or anything like that, just #ifdefs in a few places
Alex Crichton (Sep 15 2026 at 17:20):if web.h ships with the sdk though then that's all different, we'd be shipping libweb.a, but it'd also be a solved problem for clang compat then since it's only precompiled
Ben Visness (Sep 15 2026 at 17:27):Honestly, it would be great to precompile as little as possible and distribute all the bindings SQLite style (one header, one impl file). Is that feasible or do the modded toolchains need object files with mystery magic in them somehow?
Alex Crichton (Sep 15 2026 at 17:30):oh that's true it'd also need the *.o that wit-bindgen generates
Ben Visness (Sep 15 2026 at 17:30):I thought I remembered something funny there
Alex Crichton (Sep 15 2026 at 17:30):in theory it's it's just another "include this in your build" kind of file
Ben Visness (Sep 15 2026 at 17:30):what does that object file do again?
Alex Crichton (Sep 15 2026 at 17:31):encodes the WIT in a custom section that wasm-component-ld later picks up to generate a component
Ben Visness (Sep 15 2026 at 17:32):WIT or component binary stuff?
Alex Crichton (Sep 15 2026 at 17:33):elaborate on "component binary stuff"?
the object contains a custom section which is the WIT-encoded-as-wasm in wasm binary form, so sort of a wasm-component-in-a-custom-section-in-a-core-module
Ben Visness (Sep 15 2026 at 17:34):just was wondering if wasm-component-ld literally had to re-parse WIT or if it saw the component binary format
Alex Crichton (Sep 15 2026 at 17:34):ah yeah, component binary in that case
Last updated: Sep 20 2026 at 18:08 UTC