ascii_only UglifyJs option grew build sizes considerably

[hyperknot]

The recent PR (https://github.com/facebookincubator/create-react-app/pull/2596/files) for switching on ascii_only in uglify options grew our projects build size from 530 KB to 539 KB.

The reason for the 9 KB grow in size is that ascii_only doesn't seem to be a sophisticated filter, it basically converts loads of characters to unicode escape sequence. Those are not emojis but "normal" unicode characters outside the ascii range.

How to reproduce:

1. add import entities from 'entities' to a new cra app
2. build size with ascii_only: 201 KB
3. build size without ascii_only: 194 KB

[gaearon]

I wonder if we can figure out what’s breaking correctness and how to avoid those issues while keeping build smaller in general case?

[hyperknot]

I think the original problem was only with emojis, so a better filter would be to only touch the emoji range.

[viankakrisna]

It's not only emojis, regex also causes problem #2488 (comment).

As CRA users does not have access to the configuration, it's better to turn this on. Else we risk something blow up in production and cause confusion (and more people need to eject to fix it).

Some of the solution for non ascii character found in https://github.com/mishoo/UglifyJS2/search?p=1&q=ascii_only&type=Issues&utf8=%E2%9C%93 is to serve the bundle with a correct charset, but it's asking alot for CRA users as they expect that when something working on dev, it should working on production. (ps: I've tried adding charset="UTF-8" in the script tag and head postbuild, but it doesn't fix the emoji situation)

Can you provide a repo with example for this increase in size? I've tried installing and importing entities in freshly generated CRA project, but the difference in a gzipped size printed in command line is minimal, 62.13 KB vs 62.12 KB when comparing the ascii_option. The emoji repo is expected to increase it's size, because it's a working vs non working version of the bundle.

[hyperknot]

@viankakrisna gzip might hide away the differences, as many of the changes are repetitive. Have a look at the actual file sizes, you'll see the 7 KB difference.

[viankakrisna]

I think that's exactly why we print the gzipped file size in CLI, because realistically, we want to serve the production bundle with gzip. I know that the real file size also affects parsing time, but it's a cost that we need to spend for correctness (right now).

[viankakrisna]

@tbillington and @crabicode might have context on how frustrating it is to have an unexpected error in production deployment.

[Timer]

If this size increase was pre gzip, I'm not sure if there's much to worry about. Bundle size typically only matters over the wire -- it shouldn't have a noticeable impact on parse time.

[gaearon]

I think we'd rather stay on the safe side if it only affect pre gzip size.

However if there are easy remedy instructions then we could be more aggressive. Right now it's not clear to me what's the other way to solve this problem on the production server side. Is there a universal solution that works with every server?