Guy Bedford

If all goes to plan, Node.js should be defaulting to type detection in the April release, so in future we likely won't need that property (although for Node.js package publishing...

@nicolo-ribaudo happy to review any further PRs along these lines. Alternatively I'd be happy to propose some spec text if that would help, both for (1) and (2), just let...

Here's my best shot at formal trap semantics: * We make `WebAssembly.RuntimeError` the formal trap error, and update all bindgen-level validation functions to throw `WebAssembly.RuntimeError` as opposed to generic `Error`,...

For now, all errors are now `TypeError` and we added stricter error coercion in the most recent release where only `result` is permitted to coerce JS errors for called functions....

Agreed we should use a `node_modules` backtracking technique here in whatever form.

U32 lowering does coercion currently - https://github.com/bytecodealliance/jco/blob/main/crates/js-component-bindgen/src/function_bindgen.rs#L260. We could possibly move to validation with traps for all user-provided values.

Yes, currently the trap behaviour is inconsistent, some type errors trap and others coerce.

Great to hear. Note that the benefit of having this on `import.meta` is that per-module filtering can be applied to which tests run.

If the import map is defined only for `preact`, expansion / inference of `preact/hooks` seems to violate the import maps spec? Or is the idea to bend the semantics to...

Thanks for sharing the context, I missed that. I guess this only makes sense because the targets are not so much final URLs as they are intermediate package specifiers which...