Potentially removing brunch from the Phoenix new template generator

I’m not sure it’s enough to just run a bunch of parallel node process. Ie, what about final concatenation? Script precedence/ordering? Script dependencies? Different js/css bundles? module loaders? Etc? In general, if I could escape the js ecosystem entirely and not have to include any asset builder I would, but it is an unfortunate reality. I don’t think the proposed solution covers enough or would be extensible enough for folks.

An excellent article. I would also imagine that npm scripts would be a very effective way of communicating most of the information needed when somebody wants to use their favorite build tool instead - assuming that means they actually bothered to learn how to use it, rather than always relying on pre-digested configurations that are churned out by other applications.

Why I Left Gulp and Grunt for npm Scripts
Why npm Scripts?

This is already easily achievable today by swapping out a single line in your dev.ex :watcher configuration. For example, swapping brunch for webpack is maybe a 30s affair today.

I think that you simply can’t predict all or even most of the “extension scenarios” that people may want - cover the basics then there comes a point where they need to be responsible for customizing their own environment for their own needs - and at that point it is more important that the general information on the critical aspects of the build process are readily apparent so that it can be mapped over to the desired build tool.

I was thinking more along the lines of more fundamental details like expected/critical source and target file locations etc. I expect that right now some of this information could be buried in “the (default) way brunch works” - i.e. one would have to familiarize oneself first with brunch before employing one’s own build tool - I expect that npm scripts could expose that type of information in a more transparent way.

As it is, over the past two years I have been noticing a growing number of people declaring to have (re)discovered npm scripts either standalone or in combination with some higher level build tool (e.g. webpack).

All described in the article I linked and npm handles fine.

In parts:

Handled by the various things, like brunch uses something like browserify internally to do that, why not just use browserify straight? So I do, it handle concatenation, it uses babel to do transpiling, I can pass in my own files or even raw source into it without touching the file system, etc…

Also handled by browserify. Browserify itself did not exist when brunch was built, but it is basically a command-line and node library that does the same for javascript work. There are similar things for css (stylus), templates (vulcanize/crisper), webcomponents(polymer-build) , etc… (brunch’s webcomponent support is… extremely lacking, it is one of the two brunch plugins I have that require repeated recompiles because brunch does not know about them). Just call browserify straight (either the cli version or import it and use it from your npm scripts).

Again, browserify.

Specify exactly what files you want in your browserify output files, spin up an instance per output file you have, pass in the files, globs, raw source that you want it to handle.
Same with stylus for css, pass through a postcss or scss transpiler first or whatever you want too.

Browserify is also a module loader, in addition it will also auto-polyfill things that the browser does not support that you use (Object.assign for example), but only if you use them (don’t use them? it does not include them unless you override it), brunch does not, have to load your polyfills manually.

The npm method can handle anything that any other javascript build system can do (you can even call into build systems if you want, that is what I was originally doing, calling brunch watch from my npm run watch until I finished moving it over) and it is the most extensible method (unlike brunch, like holy-hell-it-is-limited), while still being more succinct than any other build system I’ve seen yet, just have to not be afraid of javascript scripts. ^.^

But yeah, this would reduce the npm dependencies downloaded, it is a more simple script structure (that can even call into a build system if anyone want, or just replace it with something else by changing/adding phoenix’ watcher). The reason I suggest it instead of brunch for the default scripts (could keep a new-brunch script or something if you want, or new-gulp or new-whatever) is it is simple, fast, fewer dependencies, and explicit. It is basically a makefile with a javascript syntax. ^.^ Easier all around though.

Ooo, more links, nice!

Well, unless you want to have webpack do what brunch is currently doing to the project, then you have to make the webpack config file. ^.^

With npm as an initial hook someone could just call their webpack/gulp/whatever-of-choice from the npm build script itself until, if they wanted, they could replace it entirely with whatever-build-system-of-choice and then change the ‘watcher’ argument in phoenix.

I have multiple watchers in my phoenix config for note (well, ‘had’, currently just have one now since I’m testing npm run watch).

The goal is an out of the box experience that Just Works without fanfare. With a basic brunch or web pack config, a user does not have to know about browserify, how to configure it, how to bundle, etc. So even if this can all be achieveved by stringing fewer deps together, end-users still have to know how those deps work individually and configure to their liking. This may work well for power users but newcomers, especially those not enthralled in js day to day, just want to compile and bundle js/es20xx/sass without pain.

I don’t find any issue with Brunch being the default configured Node asset bundler/transpiler. For me, I prefer Webpack since a do a lot of React development. However, I suspect most developers don’t care or don’t know all the nuances of choosing a Node asset bundler and just prefer to start with some that just works. Like Chris mentioned, it doesn’t take very long to replace Brunch in your application. Additionally, EEX templates are pretty awesome and fast .

Problem is that brunch is indeed painful, from teaching it to quite a few people as well as remembering my initial experience with it that was obvious.

To do the JS/es20** part is just browserify, its command-line is simple, like here is mine for my app.js:

"build:app.js": "browserify web/static/js/app/**/*.js -e web/static/js/app/index.js -o priv/static/js/app.js -t [ babelify --presets [ es2015 ] ]",

I don’t use a vendor directory but that can be added easily enough to browserify with another parameter to not have it transform those files. If you notice the same options that brunch scatters around in (a couple initially confusing) places are just right there, and you can have unique options for files too (want to run the ‘react’ babelify preset on only react files, you can do that easily here, not at all easily in brunch, if at all without making your own plugin).

For css I just have (since I use scss):

"build:app.css": "node-sass -o web/static/css/app.css web/static/css/app.scss",

And of course the "build:outputfilename" is just a convention I’ve been using, can use whatever you want.

But they do have to know about brunch/webpack, which is significantly larger of a thing to learn. I started by “Hmm, how do I output two javascript file where I can import between them”, which in brunch ended up being a couple of lines of specifying path regex’s and such, simple once I saw, but no clue how to do that at first and took a bit of research as the first couple of tries caused brunch to start throwing errors.

Where in npm, everyone knows the shell (considering calling npm/mix/etc… uses it).

Which brings up my issue, they do not ‘just work’. It works for the single JS file and single CSS file that phoenix includes, but those are trivial cases. When I expanded beyond that brunch became hell to work with. As stated, even now I have to save my file, wait 50 seconds, save my file again (or just ‘touch’ brunch-config.js to have the entire brunch watcher reload) to get the files to update properly.

I enable brunch again, I make an edit in my JS file that I have open, I save it, the phoenix page reloads…and does not include the change. I save it again, wait a bit, page reloads again and still no change, I touch brunch-config.js, wait a couple of minutes, the webpage reloads about 8 times while it compiles, then finally the change is seen. Then I notice a small bug and my element is not being cleared from the DOM, so I make the fix, save it, the page reloads while I switch to the terminal and hit then again to run touch brunch-config.js, wait a couple of minutes, and it is fixed, but now I have to make the next section…

I was dreading every-single-edit that I had to make. Maybe it is a Windows thing, but brunch is painful and its time has been increasing substantially. The NPM replacement I made this morning is significantly shorter and I’ve not had a single issue of having to recompile a file yet, plus a full rebuild now only takes the time that the longest task takes (which is elm compiling) instead of longer.

Anecdotally, I use multiple SCSS files and multiple JS files and I’ve never had issues with the transpile time. Brunch transpiles my code in a matter of seconds but I develop on OS X instead of Windows, albeit I just export a single CSS and JS file when all is finished.

I think we can come up with some nice package to do what you propose vs making it default. So those who need it would just do --no-brunch and install a package that has a task to init everything to the way you describe.