Remove dependency on Node

[malaire]

Remove dependency on Node, for example by supporting Deno.

[mpizenberg]

I have never used Deno, so I can't do this myself. The only place where Node is invoked is here to start the generated node_supervisor.js.
A quick try replacing node node_supervisor.js by deno run node_supervisor.js crashes at the first line process.chdir(__dirname) so I suppose there are a few api changes that need to be done in order to run on deno, but I guess not many. If you want to have look, there are only 3 JS files:

• templates/node_supervisor.js: 116 lines of JS
• templates/node_runner.js: 47 lines of JS, a wrapper for the compiled Runner.elm
• templates/node_polyfills.js: 63 lines of JS, some polyfilling of some Web apis for Node in order not to crash

Probably the easiest way to make that compatible is to find the equivalent deno APIs for the usage of node APIs and just make a shift of those, keeping the rest of the JS code. You can try doing that by modifying directly the files generated by elm-test-rs, they live in elm-stuff/tests-0.19.1/js.

But since deno natively supports typescript, maybe rewriting those three files in typescript for the deno variant would be more appropriate?

[harrysarson]

This thread has some tips on how to write js that works in both node and deno. Possibly useful. denoland/deno#3196.

[razzeee]

I'm not sure if supporting deno would really lead to this not depending on node. I guess you could package that logic to a wasm or deno executable.

Then again, this issue reminds me of this issue over at tree sitter. Tree sitter just needs js to parse a file, it doesn't actually run node. Still, might be an interesting read tree-sitter/tree-sitter#465

[mpizenberg]

We need an efficient JS runtime to run the tests. The advantage of deno is that it also uses V8, just like node. If an adaptation of the supervisor code in node_supervisor.js was done for another runtime, such as deno, a system could call elm-test-rs --runtime deno for example and have everything work without ever needing node. So we would not depend on node, we would depend on "a JS runtime" with options being node or deno.

[harrysarson]

Working out how to make elm-test-rs work with deno might show us how to make elm-test-rs work with via a browser (using the headless api). Then you could run unit tests in the actual browser which would be cool

[razzeee]

@mpizenberg interesting, I took the subject to another conclusion and thought you don't want to rely on anything outside your binary at all.

[harrysarson]

The other conclusion is possible with deno with https://github.com/denoland/rusty_v8. Possibly is very different from practical though and I have no idea what an implementation would look like.

[mpizenberg]

As @harrysarson said. And it would bring C++ (from V8) bindings that would mess up with musl compilation for linux. It's another level of complicated having nothing outside the binary at all and I'm not interested in solving that. At least for the moment. If Elm compiling to wasm happens before Elm integrating a test runner, we might very well bring a wasm runtime in.

[mpizenberg]

JS runtime support

Here is a detailed list of the requirements to be able to use alternative JavaScript runtime instead of Node.
This applies to Deno as well as the Web.

Main supervisor: deno_supervisor.ts

• change working directory to the one of the file: no need for deno since worker is loaded with relative URL.
• import a compiled Elm module: use trick in https://discourse.elm-lang.org/t/using-deno-in-deveopment/5885/6
• spawn a worker module: needs --allow-read
• communicate with worker
  • send messages to a worker module: worker.postMessage
  • listen to messages from a worker module: worker.onmessage
• terminate a worker module: worker.terminate() (beware the bug in self.close() preventing postMessage in worker: Messages from workers that are about to close are spuriously not received denoland/deno#11526)
• exit self process with a given exit code: Deno.exit(42)
• create events emmiters and register to them: just replace with a simple callback
• write to stdout
• write to stderr
• ability to read (listen to) single line or single JSON object from stdin:
  we can create an async iterator with this guide: https://decipher.dev/deno-by-example/advanced-readline/
  We just have to put it last in the supervisor I think.
• measure time: performance.now() with --allow-hrtime

Runner worker: deno_runner.ts

• communicate with parent
  • listen to parent messages: self.onmessage
  • send messages to parent: self.postMessage
• capture and redirect stdout to a variable (only in worker, without changing stdout behavior for the main supervisor)
  This requires changing the call to console.log in the generated elm file by a new function.
• import a compiled Elm module: use same trick to convert to ES module
• measure time: performance.now() with --allow-hrtime
• write to stderr

[mpizenberg]

Using Deno instead of Node should be possible now in PR #92 with the --deno command line argument.

[mpizenberg]

Done in #92