Add React's production aliases

[lukeed]

Using examples/hello-world as a basic starting point, these changes produce a bundle that is 1kB (min) smaller. The compilation process is also faster!

On my workhorse, I'm seeing 5.6s vs 6.0s. <-- Really marginal here, but this difference translates to a larger difference on more standard hardware. Eg, the difference is 1.5s on my laptop... and the difference will only increase with more complex projects!

Relevant thread: Twitter

[lukeed]

The change is located such that users' next.config.js can add to or override the resolve.alias field.

[arunoda]

This is great @lukeed.
I think we may need to add server aliasing as well.
I'll try something around today.

[lukeed]

Thanks! Tim mentioned the same thing earlier today so i checked it out and it's not the case. The server picks up the webpack aliases.

[rauchg]

😍

[arunoda]

I tested this with few different types of app for multiple times.
(All of these times, babel loader cache has been removed)

There's no comparable time and size differences using this PR.
(Sometimes, without this PR it'll speed up 1-2 secs. But I think it's due to some other random processes running in my MBP)

But,

The improvement comes when the user turned off uglifyjs. (Stopping that will give us around 2x-3x build time reduction)
Also it'll will reduce bundle size significantly. For our https://zeit.co, using this will reduce the size of the app.js to 1.1MB to 600KB.
(That's a huge difference)

[lukeed]

@arunoda Thanks for this! Is there anyway you can show me some of the apps you tested this on? I should be able to dig into it more this weekend. But with the hello-world demo, I consistently got a 0.5s reduction. 🤔

For our https://zeit.co, using this will reduce the size of the app.js to 1.1MB to 600KB.

This was the main incentive for the PR. 😄 'Twas the start of that Twitter thread.

[arunoda]

@lukeed check this for a mid-size app.
Unfortunately, I can't give you access to https://zeit.co :D

[lukeed]

Understandable 😜 I'll check this out.

Btw, I don't think there should be a huge time difference here -- UglifyJS still has to be slow & methodical in order to do its job well.

A possible next step might be to uglify the application code only and then inject the prod-ready React afterwards? Might not be worth the experimentation, since it'd only avoid parsing ~45kb.