Adding Babel to frontend workflow; Upgrading Webpack to version 2.

[sebworks]

Adding babel to frontend workflow; Upgrading Webpack to version 2.

Additions

• Added .babelrc as a babel Configuration file. Using the es2015 and stage-2 presets. Presets are just sets of transformations.

Changes

• Modified config/webpack-config.js to do the following:

  • Use the Babel loader
  • Enable the cache property for performance purposes.
  • Delete the second chunk entry which seems no longer necessary in Webpack 2.

• Modified gulp/tasks/scripts.js to pass webpack-stream a Webpack param.

• Updated package.json to do the following:

  • Add the necessary modules to support Babel.
  • Remove slick-carousel as it's no longer needed.
  • Move snyk as it's not necessary to run on Jenkins.

Testing

• Run rm -rf node_modules
• Run frontend.sh.
• Browse the site as expected.
• Run rm -rf node_modules
• Run frontend.sh production.
• Browse the site as expected.

Screenshots

Before:

After:

Notes

• The key performance bottleneck is the webpack.optimize.UglifyJsPlugin. There are alternatives which uglify in parallel, we should investigate if they are worth using.
• This is an interesting article: webpack Performance: The Comprehensive Guide lcxfs1991/blog#15.

Todos

• Converting some modules over to ES6.

Checklist

• PR has an informative and human-readable title
• Changes are limited to a single goal (no scope creep)
• Code can be automatically merged (no conflicts)
• Code follows the standards laid out in the front end playbook
• Passes all existing automated tests
• New functions include new tests
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged
• Visually tested in supported browsers and devices
• Project documentation has been updated
• Reviewers requested with the Assignee tool ➡️

[contolini]

Just curious: Why'd you choose stage 2? Have you looked at babel-preset-env that lets you target the browsers your project supports? (Although now that I think about it, because we support old versions of IE it probably would end up applying every plugin and transform imaginable).

[sebworks]

Why'd you choose stage 2?

It was just and arbitrary starting point. We can adjust if we find language features we want to use but find missing. The process is quite interesting, as it appears features are moving in / out of stages based on the TC39 process. https://github.com/tc39/proposals.

[contolini]

Works for me. 👍

[ascott1]

@sebworks along with this PR, we should add ES6 guidelines to our JS standards

[contolini]

1.25 -> 1.25.0

[sebworks]

@sebworks along with this PR, we should add ES6 guidelines to our JS standards.

@ascott1 ok, I will work on the guidelines.

[anselmbradford]

Will try to review this today!

[anselmbradford]

IIRC the redundant commons chunk calls here were for the scenario where all included scripts included a reference to a module EXCEPT common.js. In that case, since all scripts reference a module, the module's declaration should be moved to common.js automatically by webpack, instead of leaving them redundantly in each script. I tested this behavior in the old setup and the new setup and it still works as expected 👍

[sebworks]

You are correct but in order for that to work you need to set the minChunks property. The default is infinity. You can test this by setting minChunks: 3 and running gulp build. It should increase the size of common.js and decrease the size of each of individual modules. That decrease is due to the standardType being added to common.js as it's required by atleast 3 modules. Do you think we should set the minChunks property?

[anselmbradford]

LGTM 👍 nice work

[ascott1]

👍 from me as well.