Allows both `.node-version` and `.nvmrc` files to contain the same version, if they're formatted into the same version. i.e. `11.10.0` should equal to `v11.10.0`
Closes#206
Adds `fnm exec` to run a shell executable with the current node version (or a custom one provided):
```
fnm exec -- node -v # will print the current Node version in fnm
fnm exec --using 12 -- node -v # will print the version of the latest node 12 installed
fnm exec --using-file -- node -v # will print the version of the current directory's node version (based on `.nvmrc` or `.node-version`)
```
* If no version is matching => we print out a message (like we used to)
* If only one version is matching (because the user provided a specific version `6.17.1` or because the prefix match only one installed version) => the version get uninstalled
* If multiple installed versions are matched: we print out the matching installed versions and ask the user to re-run the command with the correct version to uninstall.
Note: it's not possible to uninstall using `latest` or `latest-v9.x`, ... But that's already the case so nothing has changed here.
Seems that Lwt 5 throws a weird error when using `exit(1)` inside a
promise. So instead of exiting in the command, making all executable
modules a function that returns a `result((), status_code)` is a better fit.
Relates to: https://github.com/ocsigen/lwt/issues/758
This is done by pinning gmp to a fork of `esy-packages/esy-gmp` that uses the `--enable-fat` argument, suggested by @ulrikstrid.
Here's the description of the open PR for `esy-packages/esy-gmp` https://github.com/esy-packages/esy-gmp/pull/3:
> GMP uses [Intel ADX](https://en.wikipedia.org/wiki/Intel_ADX) to do math stuff when capable for performance reasons. The pick whether to use ADX or not is being chosen on compile time, unless you specify `--enable-fat` which creates a "fat" binary that decides on runtime whether to use these custom instructions:
>
> > Using --enable-fat selects a “fat binary” build on x86, where optimized low level subroutines are chosen at runtime according to the CPU detected. This means more code, but gives good performance on all x86 chips. (This option might become available for more architectures in the future.)
>
> Without this flag, users can get "illegal hardware instruction" errors when running their binaries on a machine without Intel ADX.
>
> So, in other words, this PR enables building gmp into a binary on CI which _has Intel ADX_, and then using it on a machine that does not have it (like AMD or older Intels)
>
> To me, it sounds like a sane default.
Github URLS are different between release/version so check during
download and install using the correct path.
Adding in a check for if the curl command fails to download.
By statically linking `libgmp` on MacOS, we can avoid problems we have with OpenSSL, including dynamic linking (Fixes#110), and certificate issues (Fixes#170)
Unfortunately, it makes fnm fail to build on Windows, which is not that of a big deal. I want to say thanks for @ulrikstrid for all the work he invested into making the build pass on Windows, but I think that implementing fnm on Windows will be better off as a separate program — maybe even in this very repo, while sharing the feature tests with the Unix implementation
This PR adds a GitHub action (🎉) that checks for the latest refmt syntax.
This is done thanks to @thomsj which brought up the problems with formatting in the repo! 👏#105 (comment)
The current implementation is not ideal: it installs esy and then installs OCaml and @esy-ocaml/reason. A better way to do it is to distribute refmt as a standalone binary from the latest Reason release. This will be fast to install and therefore fast to integrate with CI.
An approach to do so is to add an artifact to the CircleCI runs, and then use something like circleci-artifacts.now.sh to fetch the artifact, extract it and profit 💰
In the meantime, it takes <4m to run it, which is much faster than the Azure Linux build, not to mention the Windows one.
Fixes#122, and adds tests for it:
The problem, I believe, was that some files were deleted before their symlink was deleted. `Unix.stat` fails on symlinks that point to missing files. We don't really care about their stat, honestly, so we can just run `Unix.lstat` and remove them.
Jo Liss