search

bytecodealliance / jco

JavaScript tooling for working with WebAssembly Components
https://bytecodealliance.github.io/jco/
Apache License 2.0
571 stars 53 forks source link

feat: support semver aware exclusions #459

Open vados-cosmonic opened 2 days ago

vados-cosmonic commented 2 days ago

This PR updates jco to support the @since, @after and @unstable annotations as implemented by the upstream Rust tooling.

Currently there are a few issues left to address:

yoshuawuyts commented 1 day ago

@vados-cosmonic incredible; thank you for working on this!

We likely need an upstream release & alignment of the new code in wit-parser that supports the annotations

There should already be a working upstream implementation pulled in. I checked with wasmtime to make sure that a working wasm-tools version was part of the latest release, specifically so that that jco could pull it in. If that's not working somehow, maybe @guybedford will know more?

vados-cosmonic commented 1 day ago

Hey @yoshuawuyts thanks for chiming in, so it turns out I was using the git dep for wit-parser which was my problem!

wasmtime-environ (the last git dep) does need a release (unless I'm understanding incorrectly) -- I'm looking at the commits between main and release-22.0.0 in wasmtime/wasmtime, and in particular the commit I need (that aren't released AFAIK) is:

https://github.com/bytecodealliance/wasmtime/commit/9bdb731ab653a3845a1fa6cb6fcb20505c049ee8

yoshuawuyts commented 1 day ago

Oh, rightt - yeah that's the "semver-aware exports" feature wasmtime was missing and only recently implemented (to my surprise that went faster than expected!). My assumption was (and this might be wrong) that both jco and wasmtime would resolve this issue in separate ways. So all we needed was a new version of the parser in wasm-tools, not a working resolver impl in wasmtime. But if jco uses wasmtime-environ for its resolution, it makes sense that we'd want to reuse it.

I'm not sure what the exact right path here will be. What I do know is that Wasmtime 0.23 will be released in two weeks - which is about a week before we're set to release WASI 0.2.1. So one option might be to have a patch ready which we can merge the moment a new wasmtime version is released, making it part of the jco release a few days later.

That does cut it a little close for my taste, so ideally we could land + test the patch well before then. I don't know what our options beyond that would be? - Floating patches? Pulling a non-release version of wasmtime? Ask wasmtime to pretty please push a patch version of wasmtime-environ with these changes? Implement the resolver logic ourselves on top? I don't know - but I think this is probably a @guybedford question.

vados-cosmonic commented 1 day ago

Ahhh thanks for laying this out -- this helped me understand a lot more of the high level plan -- happy to hear how best to move forward here. IIRC @ricochet is also capable of helping with the upstream release if necessary here.

Right now with the code in this branch wit-parser still doesn't seem to recognize @since, which has me a bit confused. Maybe I'm missing something even after setting Resolve's all_features...