This course is made up of 16 lessons, each approximately 5 minutes in length.
So the course lasts a little over an hour if you want to learn it all.
The whole course was available for free last weekend, unfortunately I didn’t hear the news until it was too late.
From now on, the first video clip is available free for all. The rest are for Pro members only. As I am not a Pro member, this article is not really a review, but provides information for you if you are interested in learning Webpack.
Kent explains that for our module.exports, webpack 2 uses a function that takes a environment object and returns our webpack configuration object.
We also see the package.json file we see the scripts section. This defines:
- build – our development build
- build:prod – our production build
We also see scripts for copy-files, clean-and-copy, prestart, and start
This webpack configuration is setup to use Karma and the instanbul code coverage tool.
Pro member lessons
It’s quite common to make a mistake while developing your webpack configuration. A simple typo can cost you hours of development time. With webpack-validator, you can save yourself a ton of time by validating that your webpack configuration is free of common mistakes.
The less code you can send to the browser, the better. The concept of tree shaking basically says that if you’re not using some piece of code, then exclude it from the final bundle, even when that piece of code is exported from a module.
Because ES6 modules are statically analyzable, Webpack can determine which of your dependencies are used and which are not.
If you’re going to use code splitting with Webpack 2, you’ll need to make sure the browser has support for the ES6
Promise API. This means that if you are required to support an old browser, you need to provide a polyfill.
Polyfilling is relatively trivial to do with Webpack, but because Webpack itself depends on this particular polyfill, you have to come up with another way of doing so.
As a Single Page Application grows in size, the size of the payload can become a real problem for performance. In this lesson, learn how to leverage code splitting to easily implement lazy loading for your application to load only the code necessary for a particular feature or functionality.
Leveraging the browser cache is an important part of page load performance. A great way to utilize this cache is by versioning your resources.
Often, you have dependencies which you rarely change. In these cases, you can leverage the CommonsChunkPlugin to automatically put these modules in a separate bundled file so they can be cached and loaded separately from the rest of your code (leveraging the browser cache much more effectively).
You can fine tune several webpack plugins to make your bundle as small as it can be for your specific application. However there are a few things you can do for pretty much every application to make it smaller and run faster.
Combine several webpack plugins to optimize things for a React application (this is also applicable for non-React applications as well).
When you have a dependency that does not export itself properly, you can use the
exports-loader to force it to export the pieces of the file that you need.
When you have a dependency that has dependencies on global variables (like jQuery or lodash) or assumes that
this is bound to
window, you can use the imports-loader to provide those dependencies explicitly.
There are several steps involved with setting up
Karma to work on your webpack project.
Initialize our karma configuration and setup our
Install Chai and karma-chai so you can use the
expect assertions in your tests.
When writing tests run by Karma for an application that’s bundled with webpack, it’s easiest to integrate webpack and Karma directly together.
karma-webpack plugin and reuse our existing webpack configuration to preprocess our test files with webpack.
How much of your code runs during unit testing is an extremely valuable metric to track. Utilizing code the
karma-coverage plugin and
babel-plugin-__coverage__ plugin, we can get an accurate measure of how well we’re covering the files that we are testing.
If you’re only instrumenting the files in your project that are under test then your code coverage report will be misleading and it will be difficult for you to track or enforce improvements to application coverage over time.
Ensure all source files are included in coverage reports, and enforce a specific threshold so you can work toward improving application code coverage.
Pluralsight course: Webpack Fundamentals by Joe Eames
Pluralsight course: Building Applications with React and Redux in ES6 – has a module on Setting up your environment using Webpack