Use Uglifier Harmony mode

[michaelbaudino]

This commit overrides the default Rails configuration to use the Harmony
mode of Uglifier, which support ES6 syntax, as mentioned in their README
file:
https://github.com/lautis/uglifier#es6--es2015--harmony-mode

[ghost]

Let's remove the unneeded magic comment and remove the comment, then merge it.

[ghost]

There are no string literals in this file.

[michaelbaudino]

I know, but our Rubocop ruleset makes the magic comment mandatory 🤷‍♂️

[ghost]

OK, maybe we could reconsider whilelisting rules vs. blacklisting? ;-)

[ghost]

I was going to merge, but I'll avoid since the build is "broken".
However, I think it's only because of some default rubocop rules :-(

[michaelbaudino]

Hrm, it's interesting 🤔

The current offense is actually due to our codestyle disabling Metrics/LineLength, thus the Style/IfUnlessModifier has no length limit to try to rewrite if condition with single-line body (if something; do_this; end) as a modifier (do_this if something).

It expects us to rewrite this if statement like that:

Rails.application.config.assets.js_compressor = Uglifier.new(harmony: true) if Rails.application.config.assets.js_compressor == :uglifier

Which is actually obviously too long 🤷‍♂️

I see 3 options here:

1. Disable Style/IfUnlessModifier in our codestyle

2. Enable Metrics/LineLength in our codestyle (but iirc we agreed it could be a pain and was an overall good practice anyway, not Ruby-specific)

3. Use the following workaround here:

   if Rails.application.config.assets.js_compressor == :uglifier
     Rails.application.config.assets.js_compressor =
       Uglifier.new(harmony: true)
   end

   ... because Style/IfUnlessModifier doesn't run since the body is now 2 lines long 🙈

What do you think?

[ghost]

I agree that Rubocop suggestion isn't acceptable here :-(

1. I'd prefer this option, given the context.
2. I'm not against enabling it, but I agree it "shouldn't" be necessary.
   However, I'm not sure the "pain" was about line length, IIRC the annoying
   ones were block lengths or other similar metrics.
3. I dislike it: "problems/bugs" of our linter shouldn't have an impact on how
   we write code.

So personally, I'd go with first option.