In the long term, it makes sense to me for elm-format to be included with Elm platform. This is what gofmt did, after all. However, I can also see some benefit to having it being a separate package, installable via npm. I would also like to make a node interface to it, so that I can hook it up to webpack and enforce elm-formatted code regardless of platform.
I'm happy to do the leg work here. Just wanted to hear your thoughts @avh4
Yes, I'm hoping to include it in Elm platform 0.17 or the version after.
I'm not a fan of the npm wrappers/installers for elm-test and elm-compiler. (I'm more interested in getting proper homebrew/apt-get/chocolatey packages created for elm-platform.) But if you make one, I'd be happy to link to it in the README. If there are any changes to the CLI that would make it easier to use in webpack etc plugins, suggest them in separate issues.
Okay, yeah, I'm going to go ahead with this - the benefit of having an npm wrapper is that we can get it to install binaries local to a project when we pack them with webpack etc.
I'll let you know when I have something that works, we're probably gonna have a stab at this in the next couple of weeks or so.
I think in an ideal world you have npm install -g elm and no other wrappers needed.
The other nice thing about an npm wrapper for Elm itself is that it means you can one-line install Elm onto any CI server running Node (which you already need in order to execute elm-test).
But yeah, having both elm-test and elm-format ship with the Elm Platform would be :metal:
That is actually something else Golang does very well - it ships with a go test command, which will look for files with the name Test<x>.go in the current project and run them with the tester. It's an awesome way of encouraging TDD - it's a lot easier to get started with tests if you don't have to first download all sorts and set up a suite
@eeue56 I like that idea! We can't quite follow the same algorithm because we need a separate elm-package.json, but being able to run elm test on a fresh project and have it Just Work seems like a noble goal. Mind opening an issue on https://github.com/rtfeldman/node-elm-test for that?
Given Elm, Elm Test, and Elm Oracle seem to have settle on npm for now, would it make sense to also package Elm Format on npm?
Personally, I am more interested in having homebrew / apt / chocolatey packages. But if someone wants to make an npm package, I would be happy to include it. If you do, please make a PR to elm-format to add instructions for how to build and publish the npm package (see the archlinux package for an example https://github.com/avh4/elm-format/tree/master/package/linux/archlinux )
I agree with getting this into the elm platform. An npm package would be duplication of effort and one more thing to deprecate and clean up later, since moving elm-format into platform would likely make it available via npm install elm.
I just discovered
brew install --devel homebrew/devel-only/elm-format
Is that something I could use?
Just a curious question, any updates on this? Installing elm-format currently seems tedious (manually downloading, unpacking, and moving to, say, /usr/local/bin). Installing from homebrew/devel-only tap brings in ghc and cabal-install to build it on download when elm-format is already available as an executable (not to mention building from source is kind of slow).
I understand that ideally it should be integrated into elm-platform (which is already on Caskroom/cask/elm-platform), but until it is, it would be nice if it's just a simple npm i -g elm-format for installation.
With interests in Elm is currently on the rise, I think making it easier for people to write good and consistent code would be for the best :)
We use the following scripts for downloading elm-format
#!/bin/bash
set -ex
ELM_FORMAT_VERSION="0.4.0-alpha"
function download_elm_format {
VERSION="$1"
if [ -e "bin/elm-format-$VERSION" ]; then
return
fi
if [ "$(uname)" == "Darwin" ]; then
ARCH="mac-x64"
else
ARCH="linux-x64"
fi
DOWNLOAD_URL="https://github.com/avh4/elm-format/releases/download/$VERSION/elm-format-0.16-$VERSION-$ARCH.tgz"
curl -L -o "elm-format-$VERSION.tgz" "$DOWNLOAD_URL"
tar zxvf "elm-format-$VERSION.tgz"
mv elm-format "./bin/elm-format-$VERSION"
rm "elm-format-$VERSION.tgz"
}
#!/bin/bash
set -ex
source ./script/elm-format-helpers.sh
if [ "$1" == "--local" ]; then
echo "WARNING: Using local verion of elm-format"
ELM_FORMAT="elm-format"
else
mkdir -p bin
download_elm_format "$ELM_FORMAT_VERSION"
ELM_FORMAT="./bin/elm-format-$ELM_FORMAT_VERSION"
fi
Thanks for that, @eeue56. However, I think maintaining one's own script might not help "distributing" elm-format... or am I wrong?
If the integration to elm-platform is not going to happen soon and unless someone is already working on it, I'd like to give packaging elm-format for npm a try. Will it be okay?
Currently I'm thinking of approaching it like what phantomjs-prebuilt npm package is doing with phantomjs; basically, it will:
elm-format is already present in path (if it is, do nothing);elm-platform).What do you think?
Please do. Check out how out how it's done for the rest elm here -> https://github.com/elm-lang/elm-platform/tree/master/installers/npm
All right, I'll fiddle with this and use that as a reference. Thanks!
Most helpful comment
Thanks for that, @eeue56. However, I think maintaining one's own script might not help "distributing"
elm-format... or am I wrong?If the integration to
elm-platformis not going to happen soon and unless someone is already working on it, I'd like to give packagingelm-formatfor npm a try. Will it be okay?Currently I'm thinking of approaching it like what
phantomjs-prebuiltnpm package is doing withphantomjs; basically, it will:elm-formatis already present in path (if it is, do nothing);elm-platform).What do you think?