Feature: Set output file

[halohalospecial]

@mybuddymichael, @splodingsocks do you think a way to set --output should be a feature of this package? Right now, we have --output=/dev/null. If I want to output to a .js file, I have to run elm-make in the command line with --output set to the output file.

Cc: @rofrol

[rofrol]

@halohalospecial I also saw this in the source code, but for me linter-elm-make creates dist/elm.js

Edit: Now I remember that I've change this locally. It would be nice if this option would be configurable

[mybuddymichael]

I do not think it should be a feature. I think this should continue to simply be (more or less) a linter. The fact that we use elm-make behind the scenes is an implementation detail, to my mind, and should remain so. I don't think this package should be an interface to the full compiler.

[rofrol]

That's a pitty. Right now I've modfiied linter-elm-make so it outputs to dist/elm.js. I also have browsersync set and I'm compiling always Main.

With that I don't have to set any watchers for '*.elm'. also I don't have to compile project twice.

With simple save I can see linter output and also browser is refreshed with new changes. And elm-make isn't so fast so this feature would be desirable.

[rofrol]

Ideally linter should communicate with something like https://github.com/jonathandturner/rls
and shouldn't run elm-make by itself, so there is no double compilation.

[mrmurphy]

@rofrol it sounds like you have a pretty neat setup going there! But even so I agree with @mybuddymichael. I think this package should stay a linter, and the fact that the compiler is what's used for linting should stay (as much as possible) and implementation detail.

Just my 2 cents.

[rofrol]

@splodingsocks And the reality is you have to compile twice. In ideal world, linter would send compilation request to sth like rls. Since linter runs compiler directly, let people use the fruits of this labor.

elm compiler is slow on big projects, we don't have incremental compilation, we don't have rls. That's what we have.

Like I said I can modify linter locally, but that might not be ideal situation if we want to promote Elm as a nice platform for using.

[rofrol]

Relevant post by @rtfeldman:

Part of my wish list would be a protocol editors could use to subscribe to information on builds that were kicked off by other tools.

Right now I have Atom configured to elm-make the current file on save so I can see errors in the editor. I also have Webpack watching my local filesystem for changes, and rebuilding the appropriate Main file as necessary.

This means when I hit save I'm getting two elm-make processes doing the same work. (Also I'm getting elm-format re-running the parsing step in order to preserve e.g. comment positions, but that's out of scope here.)

It would be great if both of those tools could talk to elm develop instead of elm make, so instead of having Atom say "run elm-make on save" it could just subscribe to elm develop for live updates on builds that were kicked off elsewhere (e.g. by webpack).

This would prevent duplicated build effort while still giving me the "recompile on save" experience in my editor. Atom wouldn't actually be requesting new builds on save anymore, but I wouldn't know or care. Whenever I'd save, Webpack would detect the filesystem change, ask elm develop for a rebuild, and then elm develop would tell Atom about the result. It would feel the same as "compile on save" to me as a user, except it would finish in something like half the time it currently does.

https://groups.google.com/d/msg/elm-dev/aDWFBg72Wt4/5Lg_8p21BAAJ

[raffomania]

Of course, what Richard says makes sense, but we're a long way from getting there. I think adding an output file option would be a pragmatic solution for now -- Elm compile times are really not the best at the moment, and compiling twice just makes it so much worse.