Phoenix 1.4 (rc.2) with Brunch - phoenix.js is not transpiled

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.

As ignorant as I am, all the other libraries we are using are already transpiled, and brunch does not have to compile them. phoenix.js seems odd here

(Haven’t tried 1.4 yet).

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”.

When Babel can’t find a browserslist somewhere it assumes:

> 0.5%, last 2 versions, Firefox ESR, not dead .

Included browsers e.g. IE11 but not below.

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

I ended up replacing uglify-js with terser which is a maintained fork, supporting ES6: https://www.npmjs.com/package/terser

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

Ha, so I found a bug.

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.

How to write and build JS libraries in 2018

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.

It was just a simple misconfiguration. I’ve addressed it here: Fix Phoenix.js ES5 output, upgrade webpack by davydog187 · Pull Request #3126 · phoenixframework/phoenix · GitHub

You can pull in Phoenix master for a working build.

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.