webpacker: webpacker 3.2.1 hardcodes uglifyOptions: { ecma: 8 } which ignores Babel target options and breaks IE11 compatibility
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 a5e76b80887c929105221a4333ed0c05ac99d17e 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
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 25
- Comments: 30 (7 by maintainers)
We are experiencing the same issue, and just fixed it by changing our
production.js
toI 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!
You can use this as a workaround in your
environment.js
until the fix goes mainstream: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:
and was throwing this error in IE11:
After @danielma 's fix, the code looked like proper ES5:
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.@renatodeleao This is fixed on the master branch will make a release later in the week.
This is quite a big issue IMHO and took hours to track down. @gauravtiwari possible to get a fix in for this soon?
I think it should work out of the box for v4. It now uses TerserPlugin, and the corresponding configuration settings are here: https://github.com/rails/webpacker/blob/1e9e2d04de100a3d5beb085ccaad061440265dc7/package/environments/production.js#L48-L52
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.Just upgraded from webpacker v3 to v4. I had been using @danielma’s solution :
But that now throws an error in v4
Error: Item UglifyJs not found
, so I tried @renchap’s v4 solution:but that gives me an error:
TypeError: Cannot set property 'ecma' of undefined
Any ideas how to fix for webpacker v4?
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
:This was the result of our investigation as well. However, the workaround should not have been needed since 3.5.5 anyway.
Will push an option for this in environment during the weekend. In meantime, please use the solution suggested by @danielma
You can see the uglify behavior on this online example. Set the input to
a = "\uD835\uDD04";
and set the appropriate options: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.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.
Great, thanks for reporting back 👍
Closing this issue…
it works! i updated the Gemfile and npm package, then all good. thank you @gauravtiwari
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
with this statement
+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.