Update to webpack 4

[mzgoddard]

Proposed Changes

• Update to webpack 4
• Replace buffer-loader with arraybuffer-loader (Use arraybuffer-loader in place of buffer-loader #1111)
• Replace babel-preset-es2015 with babel-preset-env (Update babel-preset-es2015 to babel-preset-env #1112)

Reason for Changes

This PR updates scratch-vm and represents what will be PRs for the other 8 projects (including scratch-gui) with webpack builds used by scratch-gui. It should be easier to use this as a launch pad for discussing what will be very similar PRs once this one is figured out.

One of the goals of this PR and its siblings for the other repos is to standardize the build tools across the repos. Some packages use webpack 1, 2, or 3 and some use babel-preset-es2015 while others use babel-preset-env.

webpack 4

webpack 4 launched a stable version at the end of February. Along with a continued focus in build performance, webpack 4 introduces a number of quality of life features. webpack 4 has minimal to no configuration with its mode option that can be set to development or production. Each mode then configures defaults for other webpack options following "good practices".

The development mode helps debugging in a few ways. One benefit that's easy to notice for anyone that's looked at webpack output is the module identifier.

Instead of numbers by default webpack 4 development mode defaults to the relative path to the resolved file and require calls display the path the statement requested.

Production mode focuses on better optimizations like using uglify-es, supporting more recent js syntax and, and adding side effect free optimizations. Using the latest lodash-es in js modules (import {isObject} from 'lodash' syntax), webpack can import only the functions needed from lodash-es as those functions are modified with side effects in lodash-es and uglify-es will prune the remaining dead code.

buffer-loader => arraybuffer-loader

#1111

buffer-loader inlines binary files in webpack builds by encoding them as numeric literals. Each byte encoded this way uses 2 to 4 bytes. arraybuffer-loader encodes the data as base64 and decodes it back into numbers at runtime using 1.33 bytes for each encoded bytes. arraybuffer-loader saves on bandwidth to download the resulting js and the amount of space in memory the script takes.

babel-preset-env

#1112

babel-preset-es2015 is no longer maintained. If newer syntax from ES7 (ES2016) or ES8 (ES2017) is not used, babel-preset-env when updated to newer minor versions will keep transforms for used syntax up to date. Like autoprefixer used in scratch-paint and scratch-gui we can set the target browsers babel-preset-env should transform for with browserlist.

RAM used

This change to webpack-4 (arraybuffer-loader) in a built copy of scratch-gui opening a default project reduces the memory reported in use for the JS heap on a recent MacBook Pro from 54MB to 42MB.

A Samsung Chromebook Plus goes from 28MB to 21MB.

File size

scratch-gui built with webpack-4 (arraybuffer-loader) versions of the module reduces the file size of the produced lib.min.js file from 12.7MB (4.0MB gzipped) to 9.2MB (3.6 gzipped).

Test Coverage

Passes lint, builds, and supports existing tests.

I'll update this PR soon with links to scratch-vm builds on my fork's github pages.

scratch-gui builds with vm change

With this pr's change: https://mzgoddard.github.io/scratch-gui/20180502/webpack-4/
Develop when this PR was made: https://mzgoddard.github.io/scratch-gui/20180502/develop/
Build with this change #1105 and #1106: https://mzgoddard.github.io/scratch-gui/20180502/no-boiler/

[rschamp]

Thanks @mzgoddard! This looks great!

Would you mind breaking the upgrade, arraybuffer-loader and preset changes into separate PRs (unless the upgrade is dependent on them)? Just so we can revert more easily/granularly if we need to.

[mzgoddard]

@rschamp sure. The different changes are not dependent on each other. The copy-webpack-plugin and worker-loader version updates will stay in this PR since they do relate to webpack 4.

[kchadha]

Looks good to me. Thanks for breaking up the PR @mzgoddard.

I think @rschamp or @paulkaplan should give final approval since they know more about what's happening.

[rschamp]

Just one nit, and then this is good to go. Thanks @mzgoddard!