bytecodealliance
chore(deps): update upstream wasm deps to *.227.1
~~This PR is blocked on merge of upstream orca PR:~~
~~https://github.com/thesuhas/orca/pull/241~~
~~This PR is blocked on a newer release of js-component-bindgen~~
This PR updates the upstream ecosystem dependencies to *.227.1.
In addition to requiring an update to the co-dependent js-component-bindgen crate, some tests that previously shouldn't have worked (?) needed to be updated.
~~Hey @tschneidereit this is also ready to go now, with releases in other upstream (and technically downstream) projects.~~
[EDIT] Spoke too soon here, I'm seeing failures in http-server which are new/unexpected after rebase to main, need to investigate.
Note Jco is waiting on a componentize-js release, but not because of these deps -- it's waiting for the other fixes, so this doesn't need to delay a release cycle!
Note -- given the change to parser code underneath the updating of the upstream dependencies, the commits in this PR should likely trigger a breaking change for downstream consumers (existing WITs that were written against older versions of the upstream crates will no longer work)
In fitting with conventional commits, this recommendation is reflected in the commit title:
chore(deps)!: update upstream wasm deps to *.227.1
Note -- given the change to parser code underneath the updating of the upstream dependencies, the commits in this PR should likely trigger a breaking change for downstream consumers (existing WITs that were written against older versions of the upstream crates will no longer work)
Can you say more about why you expect breakage here? The WIT parser should be expected to retain compatibility with any inputs, perhaps except for esoteric corner cases.
It's exactly those esoteric corner cases that we ran into here :sweat_smile:
https://github.com/bytecodealliance/ComponentizeJS/pull/204/files#diff-a561630bb56b82342bc66697aee2ad96efddcbc9d150665abd6fb7ecb7c0ab2f https://github.com/bytecodealliance/ComponentizeJS/pull/204/files#diff-10615bb4c867fbf0a77fbf73c5463c1f83053cb20e4fa1622d045b3bd91ae996L134
It's exactly those esoteric corner cases that we ran into here 😅
Oh, I never replied to this: I understood your comment to say that we should expect substantial breakage in the wild, as opposed to this specific pattern. The change to disallow named, and multiple, return values was made with the assumption that that functionality isn't in active use in the wild. Let's hope that assumption holds!