Native ARM and Deno runtime in elm-test-rs

Hey all, I’ve just spent some time on two things people previously asked

  1. Native binary for ARM device (such as Apple M1)
  2. 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.

Thanks and have a great weekend!

14 Likes

I am testing on Windows 10 and am curious about the switch to Deno.

I went via the commits list to Also use logs.length = 0 in node_runner.js · mpizenberg/elm-test-rs@25377c2 · GitHub to find the artifact and found this link https://github.com/mpizenberg/elm-test-rs/suites/3375374767/artifacts/79521712

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:

When using the --deno option on those projects, I get following error:

Error: Deno supervisor failed to start

Caused by:
    The system cannot find the file specified. (os error 2)

Tested with our app on Apple M1, arm build works flawlessly, little faster though!

2 Likes

Great to hear that it’s working on Apple M1!

By the way, @Viir issue with Deno on Windows has been solved with the latest version in the PR branch

1 Like

Thanks a lot!
I see it works on my machine now with the latest commit.

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.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.