elm-tooling/elm-tooling-cli

Manage Elm tools.

elm-tooling-cli's Issues

tests

I see that tests are mentioned in the spec. elm-test-rs could fit well with elm-tooling since it is an executable not depending on npm. In such cases, a tests section could be used directly if present. However, by default the command line expects files as arguments, not directories. I can see two convenient ways to spec it. Either globs are authorized in the tests section, or only directories, and the tests runner convert those automatically to something like dir1/*.elm dir2/*.elm ...

`elm-tooling install` fails with [email protected]

Description

elm-tooling install command seems to fail with [email protected] .

$ cat ./elm-tooling.json
{
    "tools": {
        "elm": "0.19.1"
    }
}

$ npx elm-tooling install
/home/nokazn/app/repro/elm-tooling.json
ERR! elm 0.19.1

elm 0.19.1
    < https://github.com/elm/compiler/releases/download/0.19.1/binary-for-linux-64-bit.gz
    > /home/nokazn/.elm/elm-tooling/elm/0.19.1/elm

    curl -#fLw "" https://github.com/elm/compiler/releases/download/0.19.1/binary-for-linux-64-bit.gz
    The above command exited with exit code 2:
    curl: option -#fLw: blank argument where content is expected
    curl: try 'curl --help' for more information

$ curl --version
curl 8.6.0 (x86_64-pc-linux-gnu) libcurl/8.6.0 OpenSSL/3.2.1 zlib/1.3.1 brotli/1.1.0 zstd/1.5.5 libidn2/2.3.7 libpsl/0.21.2 libssh2/1.11.0 nghttp2/1.60.0 nghttp3/1.2.0
Release-Date: 2024-01-31
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTP3 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd

I think -w "" option for curl in the below line (which seems to be introduced in #62) is not supported from [email protected] .

elm-tooling-cli/src/commands/Install.ts

Lines 553 to 556 in 5582d73

	// `-w ""` overrides `-w "\n"` which people might have in their .curlrc due to this:
	// https://stackoverflow.com/a/14614203/2010616
	// Otherwise they’ll get a byte/hash mismatch due to the extra newline.
	const curl = spawn(env, "curl", ["-#fLw", "", url]);

curl wouldn't fail without this -w "" option even in 8.6.0, and the current installation command succeeds with curl 8.5.0 .

I wondered I could contribute to fix this firstly, but have no idea to address this. 😢
Thank you.

Error installing elm-json on Travis CI - Windows container

I have a Windows (1809) container on Travis CI running with elm-test. But I get the following error from elm-tooling:

Failed to download:
< https://github.com/zwilias/elm-json/releases/download/v0.2.10/elm-json-v0.2.10-x86_64-pc-windows-msvc.tar.gz > C:\Users\travis\AppData\Roaming\elm\elm-tooling\elm-json\0.2.10\elm-json.exe
tar exited with exit code 2:
tar: C:\Users\travis\AppData\Roaming\elm\elm-tooling\elm-json: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now

Consider installer that doesn't require npm

It'd be great to get npm off of my dev system -- any chance elm-cli-tooling could have an installer that doesn't require npm?

Add support for elm-test-rs

This involves:

• Easy: Adding links to the executables in https://github.com/lydell/elm-tooling.json/blob/main/helpers/known-tools.ts
• Medium: Adding support for .zip files on macOS and Linux (so far only elm-format for Windows uses .zip: https://github.com/lydell/elm-tooling.json/blob/5ad521d58dfd6ef98398ed00c77b065eeb0ac199/commands/install.ts#L602-L607). I think this needs to use the unzip executable if it’s available – it seems to be available on Alpine Linux. Alternatively, convince @mpizenberg to use .gz or .tgz, at least on non-Windows. EDIT: Next version is .tar.gz, should be easy to do.
• Decision: Deciding if elm-tooling init should include elm-test-rs or not. Currently that command includes the latest version of all known tools, but maybe we don’t want to include elm-test-rs until it’s considered more stable or is more popular.
• Decision: Deciding if we should wait for elm-test-rs to become more stable first. elm-tooling is built around the fact that the tools it supports are slow and stable. For a tool with rapid releases, I would have to release new elm-tooling versions all the time.

Allow to use with `elm-verify-examples`

Many author's seem to rely on elm-verify-examples to ship their Elm packages, would be nice to support this library as well to be installed by elm-tooling if it is possible? 🙏🏻

Wrong binary downloaded for aarch64

On an aarch64 Linux distro, the wrong binaries get downloaded:

~/src/orla-player main !1 ❯ cat elm-tooling.json
{
    "entrypoints": [
        "./src/Main.elm"
    ],
    "tools": {
        "elm": "0.19.1",
        "elm-format": "0.8.5",
        "elm-json": "0.2.10"
    }
}
~/src/orla-player main !1 ❯ elm-tooling install
/home/minibill/src/orla-player/elm-tooling.json
elm 0.19.1: all good
elm-format 0.8.5: all good
elm-json 0.2.10: all good
~/src/orla-player main !1 ❯ file /home/minibill/.elm/elm-tooling/elm/0.19.1/elm
/home/minibill/.elm/elm-tooling/elm/0.19.1/elm: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped
~/src/orla-player main !1 ❯ uname -m
aarch64

I think elm-tooling should either fail or get the appropriate binaries

Windows 10 - tar must be installed on your system

Hi all,

I'm trying to run npx elm-test on Windows 10 (1607) and I'm getting the following error:

Downloading elm-json 0%
Failed to download:
< https://github.com/zwilias/elm-json/releases/download/v0.2.10/elm-json-v0.2.10-x86_64-pc-windows-msvc.tar.gz
> C:\Users\lukas.kostial\AppData\Roaming\elm\elm-tooling\elm-json\0.2.10\elm-json.exe
tar must be installed on your system and be in %PATH%:
spawn tar ENOENT

kill EINVAL

Is this expected behaviour? What is the recommendation for running this on systems without tar on path?

Thank you.

Allow globs in `entrypoints` field

In our project we have many entrypoints which are then compiled to a single JS. To manage the many entrypoints, we have a naming convention for the entry point modules, thus we never have to manually adapt the various configuration files in the project to pick up a new entrypoint.

It would be very helpful if elm-tooling.json would support globs in paths for the entrypoint field, thus we would never have to manually adapt this file, too.

As a workaround, we re-generate this file on each commit via a commit hook but it would be great to not have to do this kind of hacks.

Broken links on https://elm-tooling.github.io/elm-tooling-cli/cli/

The following links on https://elm-tooling.github.io/elm-tooling-cli/cli/ are broken:

https://elm-tooling.github.io/elm-tooling-cli/cli/faq#which-tools-are-supported
https://elm-tooling.github.io/elm-tooling-cli/cli/spec#tools
https://elm-tooling.github.io/elm-tooling-cli/cli/quirks

They should be:

https://elm-tooling.github.io/elm-tooling-cli/faq#which-tools-are-supported
https://elm-tooling.github.io/elm-tooling-cli/spec#tools
https://elm-tooling.github.io/elm-tooling-cli/quirks

Status of this repo (slow & stable, like Elm itself :) )

elm-tooling works, is fast and does what I need!

These days, the elm, elm-format and elm-test-rs npm packages are as tiny and secure as possible, which makes elm-tooling less relevant. (Only elm-json is left (zwilias/elm-json#51), but I’ve released @lydell/elm-json as a workaround). On top of that, pnpm lets you install npm packages with a global store similar to ~/.elm, making elm-format bring even less to the table. (This makes #22 not so important anymore.)

I would be fun to eventually implement #88. And it would be cool if elm-tooling was written in a language where you can create a small standalone binary, removing the dependency on Node.js and npm. But I’d rather focus on elm-watch and elm-safe-virtual-dom.

I’ll continue maintaining the project, and adding new tool versions as they are released, but new features will have to wait for a while.

Don’t take this as “this project is abandoned”! It’s all about time, and currently I’d like to spend time on other Elm things that I find more valuable. I’ve been silent in this repo for a long time, and I think it’s better to write about my plans!

That being said, elm-tooling isn’t going anywhere anytime soon. But I think it’s healthy to actively re-evaluate the “reasons to exist” of a tool, even though it’s the baby you’ve created yourself!

Feat request: support 0-dependency node js executables

Currently elm-tooling-cli is awesome to install pre-built executables but cannot be used to install other elm tools such as elm-test or elm-review because they require npm + dependencies. But there is at least one tool called vercel/ncc (and maybe others) able to take an npm executable and to compile it down into a single JS file or a few files (like a main + assets + workers) with all its dependencies brought in such that you can execute the main index.js file with:

node path/to/index.js

I've mentioned this already in the past, but I'm opening an issue for real now since elm-test is about to become free of the elm-json dependency, meaning it could be added solo in a elm-tooling.json and work even if elm-json is not there.

Concretely, the testing I've done is the following:

1. ncc build --minify lib/elm-test.js generates a dist/ directory with a few files, including a main dist/index.js, and a total size of 692Kb
2. Prepend the shebang line #!/usr/bin/env node to the file dist/index.js and make it executable
3. Add a link to that dist/index.js file in a PATH directory, and call it elm-test-ncc
4. Call elm-test-ncc from anywhere I'd call elm-test

The strategy above would only work for linux and mac, but I'm confident we could make something equivalent in windows. When compressed, that dist/ directory is 203kb. The small size of the compressed archive also means that installing elm-test via elm-tooling would be super fast.

Using ncc would not be required to fit the requirements, just being 0 dependency so that a simple node call is enough to execute the program.

Allow known tools to be downloaded from alternate locations through some sort of config

We use Elm and downloading from GitHub releases directly is blocked. We do however have the facility to download binaries internally and host them at a location.

Would you consider allowing the location where the tools are downloaded to be configurable, so that folks like us who are behind restrictive corporate firewalls, can still access tools and versions we have explicitly downloaded and are serving up from an internal server?

Yarn zero installs

Using later Yarn versions with zero installs enabled node_modules folder is always deleted if you run yarn add or yarn remove commands. Therefore, you always have to rerun elm-tooling install after those commands.

Would be great if we can specify the path for symlinks. Maybe as part of configuration, or as a CLI option?.

Meaning and resolution of "The downloaded file not have the expected hash!"

I made an app with create-elm-app, and when I try to run the tests with elm-test I get the following message:

    Failed to download:
    < https://github.com/zwilias/elm-json/releases/download/v0.2.10/elm-json-v0.2.10-x86_64-unknown-linux-musl.tar.gz
    > /home/zach/.elm/elm-tooling/elm-json/0.2.10/elm-json
    The downloaded file does not have the expected hash!
    Expected: 6ee94f04bebeb66d5ef322d76fd3dc828015571b92f1259776f716feaaec359d
    Actual:   ce0a8e237a5ac11e8dc4737c6a7adea8464cf3e0544d5dc84f7c96f74e4278dd

After a bit of poking around I can also try ./node_modules/.bin/elm-tooling init, which succeeds, and a corresponding elm-tooling install, to which I get:

    < https://github.com/elm/compiler/releases/download/0.19.1/binary-for-linux-64-bit.gz
    > /home/zach/.elm/elm-tooling/elm/0.19.1/elm
    The downloaded file does not have the expected hash!
    Expected: e44af52bb27f725a973478e589d990a6428e115fe1bb14f03833134d6c0f155c
    Actual:   e8b796172746fc7e2cd4edfd2e5a72d49ae38ddd89624caf16c6fa7226cb43c3

I would very much appreciate help figuring out the following things:

Why does elm-test appear to be downloading elm-json at runtime? (Perhaps this question is better asked over there.)
Why might I be getting these messages?
What might I try to resolve them?