Favorite tool is a term that’s hard to apply to JS build tools 
On a serious note I think there is an argument to be made for supporting a few popular choices. Doesn’t have to be directly by phoenix though.
That’s why I think external package is the most realistic option
I simply didn’t see it happen, neither in my personal project, nor at the professional one. Though in both cases, the amount of javascript used is very small, so no advance usage there.
I’m certainly not saying it doesn’t happen, but I see a lot of general statements without more concrete claims. Perhaps a description of use-case where brunch doesn’t suffice, and it’s not trivial to switch to something else might shed some light?
Ah, I’ve described many of those in a few topics recently.
Among others.
A recent specific case was adding in more webcomponent libraries, which are html based. I needed to concat the html files from a given tree in a specific order, split it it into its html/javascript/css parts, run the css into the brunch css path, the javascript into the javascript path, and the html needed to go to a further splitting and minification path. Impossible with brunch alone (even with scripts, it has no way to be given multiple outputs for a single input unless you write the output to a directory it watches, which at least on windows causes a race condition where brunch tries to reprocess assets again while the file is still being synched to the disk, thus writing out a blank section for that file, thus making me have to re-save the file yet-again for it to grab it).
Compare this to the unix philosphy of just piping programs (as in an npm run script): node-sass path/to/input/scss | postcss --use autoprefixer | cleancss > priv/static/css/app.css
Of which you can split and recombine and whatever you want, including calling other tasks so you can break it up like functions as much as you want (or write things into a myscript.js file or so and calling/piping into a node myscript.js call as even more examples). The above webcomponent horror was trivially handled by the npm part as I could do exactly what needed to be done there.
So yes, entirely replacing brunch by rewriting its large 443 line brunch-config.js file was gnarly, tried to port it to gulp, did not get any shorter but it certainly cleaned things up, then ported it to just raw npm calls this morning and ended up at less than 60 lines, each with only 1-6 calls in them (and whoa fast, gulp had the same elm sync call issue as brunch so it was not any faster than brunch).
As someone who does care about the front end, i.e. anytime when I am working in a project with as much front end code as backend code. Using npm scripts would be preferable. it’s so easy to wrap any glup/grunt/other scripts in npm scripts. npm scripts are the common denominator in the node ecosystem.
If you mean that we should be invoking a “npm run” in config/dev.exs instead of brunch directly, yes, I agree. We do even generate the proper scripts in your package.json but last time we checked they were not working on Windows. 
Hence the direct brunch call.
Could someone check if the following watcher works on Windows today?
npm: [“run”, “watch”, cd: Path.expand(“../”, DIR)]
I would be horrified if I found something was meddling with the quality of my images after I had already processed them myself 
Works fine on Windows 10 (stock project, brunch, edited files changed, etc…).
It does not, they are run through svg optimizers, png compressors, etc… It is lossless unless you use jpeg, which is lossy anyway, it just runs the images through absolute max compression, which can take some time to run but it still renders just as fast and on average compresses my images from between 20-90% off the file size. Well worth it.
And apparently it is Thanksgiving this week so my weekend ended up having to make food and deal with family, so I had about an hour of computer time total. Will make when I get time. ^.^
And later that same day after a few restarts it suddenly throws:
** (stop) :eacces
erlang.erl:2057: :erlang.open_port({:spawn_executable, 'c:/Program Files/nodejs/npm.cmd'}, [{:cd, "c:/Users/<user>/Projects/my_server"}, :stderr_to_stdout, :use_stdio, :exit_status, :binary, :hide, {:args, ["run", "watch"]}])
(elixir) lib/system.ex:550: System.cmd/3
(phoenix) lib/phoenix/endpoint/watcher.ex:15: Phoenix.Endpoint.Watcher.watch/3
(elixir) lib/task/supervised.ex:94: Task.Supervised.do_apply/2
(stdlib) proc_lib.erl:247: :proc_lib.init_p_do_apply/3
Function: &Phoenix.Endpoint.Watcher.watch/3
Args: ["npm", ["run", "watch"], [cd: "c:/Users/<user>/Projects/my_server"]]
It most certainly has access to "c:/Users/<user>/Projects/my_server", it even has write at 'c:/Program Files/nodejs/npm.cmd' as it is admin right now…
Have I mentioned how much I hate windows… >.<
100% in agreement with you Chris. Has anyone who’s worked on ElixirScript done any investigation of bridging the Elixir < = > JS gap or is the technology still too immature? Just curious.