Hey all, I’ve just spent some time on two things people previously asked
Native binary for ARM device (such as Apple M1)
Deno as an alternative runtime to Node
I haven’t merged those changes yet because I haven’t tested them thoroughly and that’s why this is a “Request Feedback” post.
If you are interested in native ARM, would you mind trying the binary for your platform? They are available as build artifacts when clicking on “details” in one of the CI checks of that pull request.
“aarch64-apple-darwin” is for Apple M1
“aarch64-unknown-linux” is for 64 bit ARM on linux
“arm-unknown-linux” is for 32 bit ARM on linux
And if you are interested in Deno as an alternative to Node to run your tests, could you try the binary for your platform in the CI build artifacts of that pull request? Use --deno to switch to Deno.
I checked if the version from the UI helps us make sure we are running the version from this branch. Not sure if there is something in the output that allows this distinction. Here is what I got from the ‘help’ subcommand:
PS C:\Users\John> ."C:\Users\John\Downloads\elm-test-rs_x86_64-pc-windows-msvc\elm-test-rs.exe" help
elm-test-rs 1.1.0
USAGE:
elm-test-rs.exe [FLAGS] [OPTIONS] [PATH or GLOB]... [SUBCOMMAND]
FLAGS:
--deno Rerun tests with Deno instead of Node
-h, --help Prints help information
--offline No network call made by elm-test-rs
-V, --version Prints version information
-v Increase verbosity. Can be used multiple times -vvv
--watch Rerun tests on file changes
OPTIONS:
--compiler <compiler> Use a custom path to an Elm executable [default: elm]
--dependencies <strategy> Choose the newest or oldest compatible dependencies (mostly useful for package
authors) [possible values: newest, oldest]
--elm-home <path> Use a custom directory for elm home [env: ELM_HOME=]
--filter <string> Keep only tests whose description contains the given string
--fuzz <N> Number of iterations in fuzz tests [default: 100]
--project <path> Path to the root directory of the project [default: .]
--report <report> Print results to stdout in the given format [default: console] [possible values:
console, consoleDebug, json, junit, exercism]
--seed <seed> Initial random seed for fuzz tests [default: <random>]
--workers <N> Number of worker threads [default: <number of logic cores>]
ARGS:
<PATH or GLOB>... Path to a test module, or glob pattern such as tests/*.elm
SUBCOMMANDS:
help Prints this message or the help of the given subcommand(s)
init Initialize tests dependencies and directory
install Install packages to "test-dependencies" in your elm.json
make Compile tests modules
Now for the actual test. I found three Elm projects in open source repositories to use this on:
I just tested with a Node-free Windows 10 system.
On that system, trying to run the tests without the --deno option failed with the following error message:
Error: "node --version" failed to start
Caused by:
The system cannot find the file specified. (os error 2)
Adding the --deno option made it work as expected.
Removing the dependency on Node made it much simpler to set up a development environment. This simplification also makes it easier to integrate into downstream projects like the web-based integrated Elm Editor.