WIP 2946 Switch to using babel-preset-env

[fzzzy]

The site now has 0 javascript errors on IE 11! (It still looks ugly though, because IE doesn't do flexbox properly)

[codecov-io]

Codecov Report

Merging #2987 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2987   +/-   ##
=======================================
  Coverage   84.12%   84.12%           
=======================================
  Files         103      103           
  Lines        2708     2708           
=======================================
  Hits         2278     2278           
  Misses        430      430

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f28034c...ad7d508. Read the comment docs.

[fzzzy]

From testing this a little more, it looks like the selective inclusion does not work unless I comment out the vendor file again. If the bundling puts common chunks into vendor, I see all of core-js and regenerator-runtime being included. If the bundling uses only a single app.js file, I see only core-js/modules and regenerator-runtime being included.

[fzzzy]

If I remove Internet Explorer, the app.js bundle gets smaller, so the selective inclusion is definitely working, but only if we don't split our bundle into app.js and vendor.js.

[fzzzy]

Marking this as WIP because as it is, all of core-js is getting included in vendor. We need some more discussion about the app/vendor split.

Also, if we include Internet Explorer support, the site does work, but looks ugly due to IE not supporting flexbox correctly. I think we should drop IE support, but again, needs discussion.

[fzzzy]

app + vendor on production is about 624k. This PR as it is (which includes all of core-js) is almost 2 megs. If I unify app + vendor but leave IE support, the bundle size is still almost 2 megs. If I remove IE support and set chrome, firefox, safari, and edge to "last 2 versions" the bundle size drops to about 1.6 megs, so the polyfills we are missing on prod are about a meg. We do get Sentry errors which are caused by missing polyfills.

[chuckharmston]

There are interesting intermdiate possibilities as well, e.g. conditional comments <https://www.quirksmode.org/css/condcom.html> that load a “Sorry! Your browser isn’t supported” message. On October 26, 2017 at 06:26:41, Donovan Preston (notifications@github.com) wrote: Marking this as WIP because as it is, all of core-js is getting included in vendor. We need some more discussion about the app/vendor split. Also, if we include Internet Explorer support, the site does work, but looks ugly due to IE not supporting flexbox correctly. I think we should drop IE support, but again, needs discussion. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2987 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABdTZ--ejeIMyIeSHZkyNJ_BgeJG4s7ks5swHqAgaJpZM4QE76s> .

[lmorchard]

We need some more discussion about the app/vendor split.

The main benefit, IMO, is that the vendor.js bundle doesn't change unless dependencies change. So, if only site code changes, then we're only shipping a new app.js to users on site updates.

But, if maintaining a separate vendor.js is preventing us from shrinking bundle size overall - it's not really worth keeping around. As-is, it's a pretty brute force mechanism I just carried over from browserify: I just flag all the vendor modules from package.json and roll them in.

I think there are some way smarter things we can do webpack-wise to get a split-out vendor.js. But, that will take a little research I think. Might just be worth ditching vendor.js for now if it's easier to get a smaller single app.js with selective polyfills

[fzzzy]

@lmorchard Ok, I think the right thing to do for now is to get rid of vendor. At least then we will be moved to babel-preset-env and the polyfills that are included depend on our browser support matrix. At some point in the future, we can look into adding vendor back in with a more intelligent strategy.

However, adding the polyfills even for just the last two versions of Firefox, Chrome, Edge, and Safari adds a whole meg, erasing all the benefits of the work we did to shrink the bundle size. :(

We actually do see a few exceptions on production because we are missing polyfills:

• fetch
• "Array.includes is not a function"

It wouldn't be hard to switch these usages to XHR and indexOf. Then regenerator-runtime might be the only polyfill we would really need again.

However, I could not get useBuiltIns: "usage" to work, only useBuiltIns: true. So the polyfills that are included depend on our browser support matrix, not our actual usage of new features.

[lmorchard]

We actually do see a few exceptions on production because we are missing polyfills:
fetch

This one should be fixed since I added the whatwg-fetch polyfill, but I don't think it's been deployed yet. That polyfill is only about 12k, which seems an okay tradeoff vs rewriting things

[fzzzy]

I'm going to close this for now and reopen it later with a new branch that uses the babel-preset-env 2 beta.