The file is now also minified, which is redundant as I am running uglifier anyway on the resulting app.js, or - rather - I would like to run uglifier on the app.js file but it crashes precisely because of it containing ES6 syntax now.
I am terrible at the JavaScript build tools to be fair, so figured I may as well ask - is there a way to use Phoenix 1.4 with Brunch, or am I basically forced to upgrade to webpack?
On slack there has also been some discussion around that from someone using phoenix.js by directly linking to it in his html, which also doesn’t work well depending on the browser. I’m not sure, but wasn’t there a way to include both and via the package.json declare which file is ES5 and which is a ES6 source file? I’ve seen lot’s of examples even for webpack, which don’t compile anything in node_modules to save on compile time.
Short answer: Yes. (Longer answer: If you really want to get into the weeds with Brunch there likely is a path through it. Maybe just act as if “phoenix.js” is one of your not-precompiled JS files and have it push it through Babel)
I suspect the underlying issue is the Babel presets being used to generate phoenix.js. More recent “default” Babel configurations aren’t sticking strictly to ES5 (unnecessarily slow) but are in fact moving towards “the part of ES2015 as it is supported by most browsers”.
I think you are right. The core of my problem is that Uglify-JS 3.x does not support “const” syntax. And this syntax is supported by majority of browsers already, so it makes sense to compile it this way.
So, my issue seems not to be related at all to brunch, which in fact works, but uglify-js-brunch.
When uglify-js-brunch is being removed, project compiles properly. Now I just need to find a replacement for it because 6MB app.js file is not something I really want
The compiled phoenix.js bundle is supposed to be es5. We switched internally to webpack for building phoenix.js, and I assumed it would be es5 output, but JS is never that easy. I’ll take a look and see what we can do. The upgrade to webpack is purely user choice and shouldn’t be required. If brunch is working for you then by all means you should stay on it
Not necessarily. I’m sure Chris is strongly motivated to not to cause any undue effort for pre-1.4 adopters but … essentially using Brunch with 1.4 (and above) is a similar position to using pre-1.4 Phoenix with anything but Brunch. The default JS tools aren’t really a core concern of Phoenix - they are merely supplied as a convenience.
If this is a Babel issue one has to remember that Babel does not target language specifications but rather feature sets as they are provided by various browsers and Node. UMD modules are starting to fall out of favour and the code therein is largely becoming ES2015.
It’s basically becoming more and more difficult to pre-compile all the various permutations that people may want, so transpiling of vendor code may become a user responsibility again.
So when you are finally ready to leave Brunch behind you may not want to blindly adopt webpack 4 but spend some time to find something that suits you - because more than likely you’ll be spending some significant time with it.
I think phoenix.js is still pretty simple and bare bones. So, ideally, you could just copy it over and load without any transpiler, compiler or bundler and it could work for you. And this is fine, I have done that recently with simple admin panel and it is great. I think if we do not have to, we should not throw away possibility to support these simple use cases.
At this time phoenix.js contains the export keyword. Browser support for modules via the script tag seems ok - but they now seemed to have settled on the .mjs extension (to leave .js for the non-module fallback).
My suspicion is that JavaScript modules were at least a partial motivator for adopting Brunch (and possibly to move from bower to npm for package management) in the first place.
