Add WASM support: --wasm flag with Node.js and Deno runtimes#4176
Add WASM support: --wasm flag with Node.js and Deno runtimes#4176lostflydev wants to merge 1 commit intoVirtusLab:mainfrom
Conversation
Implements scala-cli issue VirtusLab#3316: integrate WebAssembly with Scala CLI. - `--wasm` CLI flag and `//> using wasm` directive to enable WASM output - `--wasm-runtime <runtime>` option and `//> using wasmRuntime` directive Supported values: node (default), deno, wasmtime, wasmedge, wasmer - `--deno-version`, `--wasmtime-version`, `--wasmer-version` options and corresponding directives for pinning runtime versions - **Node.js** (default): runs Scala.js WASM output with `--experimental-wasm-exnref` flag, requires Node.js >= 22 - **Deno**: runs Scala.js WASM output; if not found on PATH, downloads from GitHub releases via Coursier cache - **Wasmtime / WasmEdge / Wasmer**: return UnsupportedWasmRuntimeError pending upstream Scala.js standalone WASM support (scala-js/scala-js#4991)
|
@lostflydev I will go over the review in the coming days (this is a hefty one, might take a bit), but in the meantime - it seems the reference doc hasn't been generated. |
| * Deno is first looked up on the system PATH. If not found, it is downloaded from GitHub releases | ||
| * and cached via Coursier's ArchiveCache. | ||
| */ | ||
| object WasmRuntimeDownloader { |
There was a problem hiding this comment.
what is the current behavior for scala-cli run --js foo.scala? i could be wrong but i would think it does not download a runtime
There was a problem hiding this comment.
Yeah, I also wondering the current behavior for that command.
I'm not sure about the policy on downloading the runtime through scala-cli (I personally don't like it though), but I believe downloading runtime stuff should be in different PR, because it's not very relevant to "supporing wasm".
There was a problem hiding this comment.
I'd treat WASM runtimes similar to how we treat node with Scala.js - the user needs to download it themselves, rather than Scala CLI doing it for them.
There was a problem hiding this comment.
Scala-cli has --jvm flag and downloads jvm by itself. This behaviour with wasm runtime downloading looks similar.
There was a problem hiding this comment.
@dos65 JVM is key to Scala CLI's core functionalities, and thus it's treated as a major dependency.
Node is considered necessary setup for Scala.js, similar to how clang is for Scala Native.
I understand this is blurry and vague, but I think we will expect the user to install WASM runtimes on their own, rather than do it out of the box here (certainly out of scope for this PR, but feel free to start a dedicated discussion or issue on this as a follow-up).
There was a problem hiding this comment.
There was a problem hiding this comment.
You got me there. 😅
Not sure why did I define the requirements this way when creating the issue.
Will amend it there.
My bad.
| * Deno is first looked up on the system PATH. If not found, it is downloaded from GitHub releases | ||
| * and cached via Coursier's ArchiveCache. | ||
| */ | ||
| object WasmRuntimeDownloader { |
There was a problem hiding this comment.
Yeah, I also wondering the current behavior for that command.
I'm not sure about the policy on downloading the runtime through scala-cli (I personally don't like it though), but I believe downloading runtime stuff should be in different PR, because it's not very relevant to "supporing wasm".
| // Standalone runtimes (future - requires upstream Scala.js standalone WASM support) | ||
| case object Wasmtime extends WasmRuntime("wasmtime") | ||
| case object WasmEdge extends WasmRuntime("wasmedge") | ||
| case object Wasmer extends WasmRuntime("wasmer") |
There was a problem hiding this comment.
If they don't work, I feel we don't need to add those options yet
|
(converted to a draft, as this clearly needs more work; feel free to change it back when it's ready to review) |
5 participants
Implements scala-cli issue #3316: integrate WebAssembly with Scala CLI.
--wasmCLI flag and//> using wasmdirective to enable WASM output--wasm-runtime <runtime>option and//> using wasmRuntimedirective Supported values: node (default), deno, wasmtime, wasmedge, wasmer--deno-version,--wasmtime-version,--wasmer-versionoptions and corresponding directives for pinning runtime versionsNode.js (default): runs Scala.js WASM output with
--experimental-wasm-exnrefflag, requires Node.js >= 22Deno: runs Scala.js WASM output; if not found on PATH, downloads from GitHub releases via Coursier cache
Wasmtime / WasmEdge / Wasmer: return UnsupportedWasmRuntimeError pending upstream Scala.js standalone WASM support (Make Scala.js Wasm backend suitable for standalone Wasm VMs (a.k.a. support "server-side Wasm") scala-js/scala-js#4991)