Semver aware WASI module resolution when dealing with imports
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 56/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- javascript, rust, wasm
- Domain
- compilers, developer-experience
Research direction
Start at ComponentizeJS's WASI import-resolution path and trace the existing direct-match handling for imports such as wasi:http/types@0.2.6. Define the compatible semver behavior around exact matches, upgrades within the supported WASI 2.x track, and rejection of incompatible older versions. Done means the stated import resolves against newer compatible worlds while jco transpile remains out of scope.
Written by the indexing model from the issue text.
Description
Right now when building components with ComponentizeJS, we deal with references WASI types via direct match only.
This is usually fine but forces certain versions (the ones supported by StarlingMonkey below) to be used. Ideally we should be able to do an exact match where possible and the fall back to a compatible semver track (usually allowing upgrades but not downgrades) similar to what wasmtime would do.
As WASI 2.x is unlikely to change going forward I think we can now do this pretty definitively here, with minimal changes required for StarlingMonkey as well.
Also note that while this issue is probably going to be unnecessary when the "new" ComponentizeJS lands, this issue is here for tracking purposes just to make sure this
A simple use case is being able to write wasi:http components against any version of 2.x and having that compile (and eventually jco transpile, but that's out of scope here!) properly. Essentially the following should never fail:
import { Fields } from "wasi:http/types@0.2.6";
(Even if the underlying world is 2.10/2.12, but this should fail if the underlying world is 2.4 probably)
Maybe it should be possible to disable this feature (i.e. supporting very specific imports), but IMO this would be a big DX improvement that is worth doing (maybe we emit some warnings or something if we're worried about it).
- Dominant language
- Rust
- Stars
- 392
- Forks
- 54
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 3
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from bytecodealliance/ComponentizeJS
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 3/5 1-2 days Newbie friendliness 52/100
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
bytecodealliance/ComponentizeJS#335 · 3 comments ·
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
All issues in bytecodealliance/ComponentizeJS
Similar issues
-
todo:perf
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
ACP agents get no MCP servers when the thread is created before the project's first worktree loads Openstate:needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
zed-industries/zed#64611 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
ontola/atomic-server#1625 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
objectionary/phie#154 ·