The usecase is this: complex enough project with ports code and SASS.
I want to have two modes:
dev: where a watcher recompiles everything on any change to an elm file or the js files used in the ports code.
prod: everything is compiled and optimized.
Ideally, the build manager should handle well errors thrown by the Elm compiler during the dev phase. It should also handle well the scenario where a new Elm build is triggered before the previous one had a chance to finish (i.e. if I edit two files and the first save triggers a compilation that doesn’t finish before saving the second file)
For the sake of clarity, what I meant by “handle well” is be able to remain reactive and consistently return to proper compilation after the file that triggered the compilation error has been amended and is error free. Some setups choke on compiler errors from time to time. My main bad experience with this involves brunch which sometimes chokes and I need to restart it in order to get back to proper compilation.
I’ve used brunch in several projects in the past, without any Elm – just regular JS and CSS. It wasn’t uncommon that the watcher became confused after a while, forcing me to restart it. This never happens to me with webpack – I find it much more reliable.
HIGHLY recommend webpack (using in prod & dev). Works amazing well both in an iterative dev env using webpack-dev-server as well as for production builds (I happen to use the google closure compiler for production builds. Epic, especially for Elm).
We have a fairly large Elm code base at this point (over 20K lines last time I checked) and use webpack to compile both Elm and the few random JS things we have lurking around.
It can be a pain to get configured just right, but once it’s working, it’s awesome, and you can customize it to your heart’s content.
We use in an Elixir/Phoenix env, but have used standalone as well.