webpacker 3.2.1 hardcodes uglifyOptions: { ecma: 8 } which ignores Babel target options and breaks IE11 compatibility

[shepmaster]

Dumping out the Webpack config in production mode, I have this piece of configuration:

"uglifyOptions": {
  "output": {
    "ascii_only": true
  },
  "ie8": false,
  "ecma": 8,
  "warnings": false,
  "mangle": {
    "safari10": true
  },
  "compress": {
    "warnings": false,
    "comparisons": false
  }
}

This seems to be from a5e76b8 and thus introduced in 3.2.1.

This affects us because we are using the remarkable package, which contains some JS like {Afr:"𝔄",}, which Babel properly converts to {Afr:"\uD835\uDD04",}, but then Uglify shortens back to {Afr:"\u{1d504}",}. This latter syntax isn't supported by IE11, causing issues in production, specifically the error "Expected hexadecimal digit".

Related to #1211

[shepmaster]

You can see the uglify behavior on this online example. Set the input to a = "\uD835\uDD04"; and set the appropriate options:

output: {
    ascii_only       : true,
    ecma             : 5,

output: {
    ascii_only       : true,
    ecma             : 8,

[danielma]

We are experiencing the same issue, and just fixed it by changing our production.js to

const environment = require('./environment')

environment.plugins.get("UglifyJs").options.uglifyOptions.ecma = 5

module.exports = environment.toWebpackConfig()

[gauravtiwari]

Will push an option for this in environment during the weekend. In meantime, please use the solution suggested by @danielma

[tbsvttr]

Even with Webpacker 3.2.2 both in package.json as well as Gemfile it only works with the fix by @danielma for me.

@danielma You are the man!

[clarketus]

I just spent a looong time googling for a solution to this. I'm going to add what I was searching for as a comment here to hopefully save other peoples time.

The IE11 error I was getting was:
SCRIPT1003: Expected ':'
This was occurring in webpack/bootstrap.js

The suggested solution here worked for me!

[tbsvttr]

@clarketus Very good idea!

@gauravtiwari When will this be fixed?

[gauravtiwari]

I am aiming to provide an option for this in Webpacker 4.0 but for now the solution suggested above is simple enough to use if you need to support ES5. Thank you.

[bjankord]

+1 to a config option. I think there are still a decent number of teams that need ES5 to support IE11. Having a first class option to change this config will be helpful.

[triskweline]

The solution by @danielma works for us, thank you.

This took a really long time to find out 😢 We thought there was a mistake with our Babel configuration.

Since Webpacker aims to provide a preconfigured pipeline that includes both Babel and UglifyJS by default, maybe the default config could target the same browsers in all processing steps? Webpacker's default .babelrc targets IE11, but with { ecma: 8 } UglifyJS will re-break the code that Babel just dumbed down to be compatible with IE11.

[lakim]

Just bumped into this problem.
We've investigated for a very long time before finding this issue. Wish we'd seen it before.

The following code in our vendor pack was using ES2015 syntax:

var r=e[i]={i,l:!1,exports:{}}

and was throwing this error in IE11:

SCRIPT1003: Expected ':'
File: vendor-43254822d2b4661a48f6.js, Line: 1, Column: 438878

After @danielma 's fix, the code looked like proper ES5:

var r=e[i]={i:i,l:!1,exports:{}}

I agree with @triskweline
I suspect that the majority of babel users are using it to transpile to ES5. Seeing UglifyJs ruining it is clearly not what they are expecting and they will have a hard time to understand where the issue is coming from.
The default config should be { ecma: 5 } and be configurable for those who will only target browsers that support ES2015, not the other way around.

[renchap]

If you updated to Webpacker 4 (Webpack 4) and are using the default config, the workaround is to add this line to your production.js:

environment.config.optimization.minimizer[0].options.uglifyOptions.ecma = undefined // the default, or 5 if you want it explicitely

[summera]

This is quite a big issue IMHO and took hours to track down. @gauravtiwari possible to get a fix in for this soon?

[1st8]

Thank you, so glad I found this issue.

Just to make this a bit more googleable, my problem was with DraftJS and IE11 telling me

SCRIPT1023: Expected hexadecimal digit

with this statement

n.textContent="\u{1f4f7}"

[bidva]

I have same problem. setting ecma 5 didn't fix the issue
still I get Syntax error on this

r=e=>

[renatodeleao]

4 hours later and only after a desperate "SCRIPT1003: Expected ':' search I got here! Just want to leave a big f*ing thanks to @danielma.

[gauravtiwari]

@renatodeleao This is fixed on the master branch will make a release later in the week.

[marvwhere]

using "4917047aae99aca1738dd06df4e60713549eef44" latest master in my Gemfile, and still running into this error. even if i only have

import 'jquery'

in my application.js

any ideas? )=

rails 5.2

my webpacker.yml is pretty defaulty

  <<: *default

  # Production depends on precompilation of packs prior to booting for performance.
  compile: false

  # Cache manifest.json for performance
  cache_manifest: true```

[decafdennis]

You can use this as a workaround in your environment.js until the fix goes mainstream:

if (environment.plugins.getIndex('UglifyJs') !== -1) {
  const plugin = environment.plugins.get('UglifyJs');
  plugin.options.uglifyOptions.ecma = 5;
}

[marvwhere]

thx! now it's working. but i'm a little confused, it's pretty the same thing like the snippet from @danielma above. but just in the environment.js ... very strange that this makes a difference.

but anyway! HUGE THANKS!

[decafdennis]

It does look like #1235 (comment) (which i didn't see) is essentially the same. Well, glad it worked. :)

[fruwe]

@decafdennis and everybody, thank you so much. tried for too long to figure that out

[kmoo]

@gauravtiwari, is this fix going to be released? I noticed there has not been a release since this fix was merged Looks like this was closed with v3.5.5!

[0x1eef]

@kmoo v3.5.5 does not fix this issue. the patch from @danielma is still needed.
the current status is that rails5+ is shipping with a stack that has broken IE11 support.

[gauravtiwari]

@R-obert Have you updated both gem and npm package to 3.5.5? https://github.com/rails/webpacker/blob/3-x-stable/package/environments/production.js#L16

[0x1eef]

@gauravtiwari i updated the Gemfile, but not package.json.
do i also need to update rails/webpacker?

[gauravtiwari]

Yep, yarn add @rails/webpacker or yarn upgrade @rails/webpacker

[0x1eef]

thanks! will try and post back.

[0x1eef]

it works! i updated the Gemfile and npm package, then all good. thank you @gauravtiwari

[gauravtiwari]

Great, thanks for reporting back 👍

Closing this issue...

[paulupendo]

Thank you, so glad I found this issue.

Just to make this a bit more googleable, my problem was with DraftJS and IE11 telling me

SCRIPT1023: Expected hexadecimal digit

with this statement

n.textContent="\u{1f4f7}"

@1st8 How did you fix this? I'm having the same issue.

[1st8]

@paulupendo probably with the solution above: #1235 (comment)

I can check for sure on monday if it doesn't work.

[JamesPlayer]

Just upgraded from webpacker v3 to v4. I had been using @danielma's solution :

environment.plugins.get("UglifyJs").options.uglifyOptions.ecma = 5;

But that now throws an error in v4 Error: Item UglifyJs not found, so I tried @renchap's v4 solution:

environment.config.optimization.minimizer[0].options.uglifyOptions.ecma = 5;

but that gives me an error: TypeError: Cannot set property 'ecma' of undefined

Any ideas how to fix for webpacker v4?

[martinsp]

I think it should work out of the box for v4. It now uses TerserPlugin, and the corresponding configuration settings are here:

webpacker/package/environments/production.js

Lines 48 to 52 in 1e9e2d0

	compress: {
	ecma: 5,
	warnings: false,
	comparisons: false
	},

[shepmaster]

I think it should work out of the box for v4. It now uses TerserPlugin

This was the result of our investigation as well. However, the workaround should not have been needed since 3.5.5 anyway.