Update dart2wasm module runner #2286
Conversation
With [1] dart2wasm got a new way of compiling and instantiation modules. Update test runner to use the new API. [1]: dart-lang/sdk@f98a84a
PR HealthPackage publish validation ✔️
Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation. |
|
Do we need to update some min. SDK version in this repo to the version with the new API? I think the test runner is shipped with the SDK (instead of fetched from pub.dev), so maybe we just need to roll this change into the SDK? Also, does this need a changelog entry? If the runner is shipped with the SDK then I think a changelog is not necessary, because the change is not visible by the users. |
|
Note: we are bringing back the deprecated API in https://dart-review.googlesource.com/c/sdk/+/387162. We should still merge this change in prep. for the removal of the deprecated API. |
|
It looks like we need to update the min SDK constraints to |
|
Given that the new API isn't available in a stable SDK yet we should also discuss whether we should wait to land and/or publish this until 3.6 is out. When do we plan to remove the deprecated API again? |
The test runner is fetched from pub to allow changes to the user code without breaking SDK changes. |
| let dart2wasm = await import('./' + data.jsruntimeurl); | ||
| let dartInstance = await dart2wasm.instantiate(modulePromise, {}); | ||
| let dart2wasmJsRuntime = await import('./' + data.jsruntimeurl); | ||
| let compiledModule = await dart2wasmJsRuntime.compileStreaming(fetch(data.wasmurl)); |
There was a problem hiding this comment.
Can we check whether an instantiate method exists and choose at runtime which approach to use?
There was a problem hiding this comment.
That would definitely be ideal, so we can still support 3.5 SDKs.
There was a problem hiding this comment.
Makes sense, I've updated this to support both APIs.
I run dart test in this package with the latest stable SDK and the main branch (before reverting the removal of the deprecated API). In both cases I got the same test results, except there was one more failure with the main branch but the test seemed unrelated (it mentions VM specific things).
|
Note https://github.com/dart-lang/test/pull/2285/files is skipping some of these for now, we should make sure to unskip them when landing this. |
Please feel free to always make any changes you think are necessary to my branches, this one and in the future as well.
Whenever the users are ready. The new API allows deferred loading, but it cannot be used in
I'm not sure what that PR is fixing exactly. It refers to a 2 year old issue that should be invalid now as dart2wasm is quite stable today compared to two years ago. |
osa1
changed the title
It was just adding additional skips to get the bots green and linking re-using an old issue for tracking that. |
| // browser's `WebAssembly` API, the compiled module needs to be instantiated | ||
| // using the JS runtime. | ||
| // | ||
| // (2) Versions starting with 3.6.0-167.0.dev added helpers for compiling and |
There was a problem hiding this comment.
It would be OK to drop support for a strategy that was only in a series of dev releases, but supporting it sounds good too.
After we have any other reason to bump the min SDK we will get this cleaned up to only the version 3 approach.
Update dart2wasm module instantiation, compilation, and invoking
mainto support all the ways dart2wasm implemented.