Hello, As noted in the Go Wiki for WebAssembly
"Note: The same major Go version of the compiler and wasm_exec.js support file must be used together. That is, if main.wasm file is compiled using Go version 1.N, the corresponding wasm_exec.js file must also be copied from Go version 1.N. Other combinations are not supported." But, I believe this leads to two problems: 1) Given a wasm_exec.js file, for example one that has been committed to a module repository and a local Go toolchain, how do we know if the version of wasm_exec.js in the repository is compatible with the local toolchain? 2) Similarly if the local Go tool chain is v1.N, but the go.mod in the repository specifies Go v1.(N-3) (just to pick an example) which version of wasm_exec.js is appropriate, v1.N or v1.(N-3)? The simplest way to solve (1) looks like adding a additional comment into the top of the wasm_exec.js below the copyright statement with a machine readable format. Something like: // wasm_exec.js as shipped with go1.23.0 Where the `go1.23.0` part should match what `go version` returns. This works nicely for humans, and also for machines. During a projects build process if a wasm-exec.js is encountered the version string can be read from the comment (via a regex for example) and compared to the output of `go version`. The project build can then fail, or copy the updated wasm_exec.js from the GOROOT for the compiler in use, with out without a warning that it has done so. I would hope that inserting such a comment into wasm_exec.js would be a minimal change to the Go teams release processes. The only alternative that I can come up with would be to add the version string into wasm_exec.js but change its meaning, so that it specifies the minimum version of the Go tool chain required. This would bring the proposed version string into line with that used in the go directive in the go.mod. This would however require a degree of backwards compatibility for the wasm target, as well as changing the current advice. (2) Seems a little harder to solve, but my guess is that whatever the go directive in the go.mod states, you would use the version taken from the local tool chain. As the local tool chain as to meet the minimum version specified in the go.mod's go directive this seems like a safe thing to do. Could someone who knows more about this than myself please confirm that? [Background for the curious as to the why of this issue is below.] Many thanks Owen [Background for the curious.... over on the Vugu project [1] we have a set of tests. Each test has two parts. A normal Go unit test (compiled to AMD64 etc) and a test main module that must be compiled to wasm. We then have a web server serve to the resulting wasm file. The Go unit test drives a headless chrome instance, that connects to the web server to request the index.html that references the wasm file. The wasm file is served and executed in the headless chrome and the Go test inspects the resulting DOM. Each test has its on local wasm_exec.js file committed into the vugu repo. As Go as moved on, we really should have been advancing the version of the wasm_exec.js in line with each new release. But we haven't. Now we have a potential issue were the wasm_exec.js could be so outdated or at least different, that it could cause the wasm module to abort at runtime - which is the only point at which the wasm_exec.js is executed. What we would like to do is at least detect this situation as part of our build process so that we know that the wasm_exec.js is outdated (relative to the version of the Go tool chain in use) so we can then abort the build. But, detecting the version of wasm_exec.js in use doesn't seem to be possible. This issue is also apparent with the tinygo toolchain. In the case of tinygo, not only does the version of the wasm_exec.js have match the version of tinygo, the tinygo version of wasm_exec.js is radically different from the one in the Go standard library.] [1] https://github.com/vugu/vugu -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/b6e2f12e50915b6cbed5afc1191883740ab6e81a.camel%40kulawe.com.
