elm binaries on PATH, elm-format

[kylecordes]

Currently, create-elm-app installs about 22,000 files, including its own copy of the Elm binaries. This creates challenges.

First, the set of binaries includes the core platform stuff but not elm-format, which many of us habitually use also. So the ~22,000 files is one file short of the set needed to get fully up and running on a machine. :-)

Second, these binaries are present and available via the wrapper but not available directly on the path, except of course by manually poking around and finding where they landed and then adding them to the path. So there is a high propensity to have version skew, in which a separate installation of the Elm binaries (to make them available for all other use other than via the wrapper - for example, from an IDE) accidentally ends up a different version from the one used the other wrapper.

I'm not entirely sure how it could best be improved. One idea is to expand the set of files slightly, land them on the path (which I think just means including them in the set that the package adds to the bucket of global node package binaries), and therefore this package would provide "everything" needed.

An alternative would be to go the other direction, and have this package require and rely on externally provided binaries. This is less convenient.

Yet another idea would be to keep the duplication (ugh) but have the software notice it and complain to the user if its internal copy of the Elm binaries mismatches a pre-existing set on the machine - by pointing it out, new developers are less likely to be surprised or confused by version skew.

[halfzebra]

@kylecordes this is something I would love to have!

The challenge is that npm installs the scripts using the strategy "the last one is the winner", which might introduce quite a lot of problems if the user does have elm-platform or elm-format installed.

I think most people use the latest version for both, so maybe we should simply expose elm-format and elm-platform?

If we could ensure that Elm Version Manager works, that would be a decent option.

I'd consider adding:

"bin": {
    "elm": ".bin/elm-proxy.js",
    "elm-package": ".bin/elm-proxy.js",
    ...

@fobos got any thoughts about possible implications?

[kylecordes]

@halfzebra What did you think of the alternative I mentioned, in which create-react-app would not install the binaries itself, because it does not necessarily have the right to do so in a global PATH way, but rather require that the user install those by the usual systemwide means?

[halfzebra]

@kylecordes this would eliminate the ambition of having one dependency. Moreover, the internal dependencies for webpack are dependent on a specific minor version of elm-platform, which suggests the idea that relying on elm-platform as a peer dependency is a bad idea.

I think the inclusion of elm-format and exposure elm-platform binaries with their original name is something that should be raised in elm-community channel.

We clearly need more opinions on the matter to make a proper decision on this issue.

[kylecordes]

@halfzebra Oh yes, I was just checking you had noticed the (worse) alternative idea for reducing the possibility for version conflict. Certainly the idea you wrote, adding those things to bin (hopefully including elm-format and the other binaries) would be very nice. It would achieve the single single dependency goal.

I guess fundamentally any NPM bin script is ultimately a wrapper (and more code of course) for a native binary. That binary is most often of course the node runtime, but offhand I can't think of any reason why on couldn't expose arbitrary binaries (like the Elm stuff) this way. It certainly seems worth a try.