Use Closure Compiler for UMD/Node bundles instead of Uglify

[trueadm]

This change introduces Google Closure Compiler (JS version) in the build pipeline instead of Uglify for the minifcation process for UMD/Node bundles. Locally, I'm seeing positive bundle size wins:

We need to thoroughly test these new builds before this can be merged however.

[gaearon]

@trueadm Do you want to set up a Jest project for flat bundles and figure out a way to opt in a few tests into it? I imagine it working the following way:

• It’s a separate Jest project configuration (see configurations @sebmarkbage added in Configure Jest with Stack and Fiber as separate projects #10214).
• It should not run by default on local npm test but should run on CI after the build step.
• It should only run for whitelisted tests. We can probably start with an explicit list of filenames. Later we can include whole directories or can use a folder name convention.
• It should run both for DEV and PROD bundles. These can be separate “projects”, and we can start with PROD. In PROD, expectDev() calls should be ignored.

[trueadm]

Seems to be something odd going on with Prettier, as it keeps failing on CI yet running Prettier locally results in no file changes. @vjeux is there something I'm missing?

[gaearon]

Did you run yarn locally?

[trueadm]

@gaearon Yes, it didn't fix the problems I was having :/

[gaearon]

Can you separate Prettier related changes into another PR? I don't quite understand why they are related to this PR. Maybe separating will also make it easier to understand what went wrong with the branch.

[vjeux]

I'd be happy to look into it but I need more details. What exactly is conflicting, what is the before/after...

In my experience, it's usually a problem where the two versions are not in sync.

[trueadm]

@flarnie I'm really eager to get this PR landed for the next release (beta?).

I'll do more manual tests tomorrow and locally test the UMD bundles but it kind of needs public support as the bundles (UMD/CJS) aren't used on FB www.

What do you think?

[flarnie]

Thanks for tagging me @trueadm :)

Here is my thought - if most folks in open source are waiting for the RC or final 16.0 release to try the latest React, then the UMD flat bundles have not been well tested by the community any way at this point. So they will need public support after each beta/RC release either way, regardless of whether we merge this.

If we wait, we may end up fixing bugs that are present with Uglify and not with the GCC (Google Closure Compiler) and so we might as well merge this.

I can try to keep an eye on issues - is there anything in particular that we know to be risky about this change?

[sophiebits]

I think this is OK to merge. Most likely syntax errors in old browsers, I guess? It doesn't feel super likely that closure will introduce logic errors.

[flarnie]

🥅 ⚽💨

[gaearon]

What bundle is this? Not really important but I don't think we have it :-)

[gaearon]

I'm curious... will it get larger again when people pass it through Uglify? Since normally people do it as a build step. It's still nice to have smaller official UMD bundles but seems like people can't take advantage of them unless they explicitly load them as a separate file we packaged.

[trueadm]

@gaearon That's a good point. I tried it locally and it doesn't seem to make the bundles any bigger for me – which is the good news! I'm merging this as per comments above.

[sophiebits]

Can you be more specific? They don't get bigger than what?

[markozxuu]

@spicyj Refers to the compression of files JS

[trueadm]

@spicyj Sorry, I wasn't very clear.

React: 6kb (GCC) and 6kb (GCC + Uglify)
ReactDOM: 115kb (GCC) and 115kb (GCC + Uglify)

Hope that explains things better.

[gaearon]

Have you verified using them via Webpack+Uglify doesn’t make them worse?

[trueadm]

@gaearon I get 120kb for React+ReactDOM bundle using webpack in production mode. So it looks like we're all good here.