These are all of my egghead.io lessons that are about webpack.

Webpack is a module bundler that bundles javascript and other assets for the browser. It works really well for applications and javascript libraries and is very simple frontend build tool.

webpack

Intro to Webpack

Webpack loaders are how you tell webpack to resolve your dependencies and you can use a loader built for the babel transpiler to easily enable ES6 code in your project. Full sourcemap support is also available using webpack's devtool property.

babel

Webpack Loaders, Source Maps, and ES6

Webpack enables modularity by allowing you to require the styles needed for a particular component. Adding preprocessors is a breeze and it simplifies the deployment of your css assets.

Webpack CSS, Preprocessors, and url assets

Currently, our library is being distributed as a CommonJS module, but we should support the browser as well. In this lesson, we're going to use [`webpack`](http://webpack.github.io/) to create a [`UMD`](https://github.com/umdjs/umd) (Universal Module Definition) build of our module so users can consume it in a browser.

javascript

Add a browser build to an npm module

Webpack is a module bundler for the web. It is incredibly powerful and enables modularity in angular applications. This is the first of several lessons to get you up and going with webpack in Angular applications.

angularjs

AngularJS with Webpack - Introduction

With Webpack and CommonJS, the way you register directives, services, etc. with your modules can be a lot more modular. See how to register a directive with an Angular module using Webpack.

AngularJS with Webpack - Requiring Directives

With Angular, most of the time you're specifying a templateUrl for your directives and states/routes. This means you need to make sure that you're loading in these templates into the $templateCache for your tests and production. Oh, and don't forget to update all your URLs whenever you move the files around! When you add in Webpack and the raw-loader, you don't need to do this anymore. Simply require the html file and your work is done!

AngularJS with Webpack - Requiring Templates

Use the latest features of ECMAScript using BabelJS with Webpack. Simply add the right loader line in your webpack config and everything just works.

AngularJS with Webpack - ES6 with BabelJS

Making your CSS modular is a difficult thing to do, but using Webpack makes this so much easier. By adding a single line to your Webpack config, you can require you CSS, Stylus, Less, etc. files right from your directives and keep everything together.

AngularJS with Webpack - Requiring CSS & Preprocessors

Testing in Angular applications takes a bit of setup. Webpack simplifies things considerably. In this lesson you'll see how to test an Angular application built with Webpack using karma, mocha, and chai.

AngularJS with Webpack - Testing with Karma, Mocha, and Chai

Using Angular with webpack makes the production build a breeze. Simply alter your webpack configuration at runtime based on an environment variable, and you're good to go.

AngularJS with Webpack - Production Setup

Angular requires some careful consideration when uglifying your code because of how angular's dependency injection system works. See how easy it is to add this consideration to your webpack configuration so you can minify your Angular JavaScript with Webpack.

AngularJS with Webpack - Uglifying your JavaScript

When you uglify your Angular code with Webpack's uglify plugin, debugging your application can be a nightmare. See how easy it is to add source maps to your bundle so you can easily debug even in production.

AngularJS with Webpack - Production Source Maps

There are several lessons that will build on top of this project. It is a fairly standard, small webpack bundled project. In this lesson we’ll explore the project a bit so you’re familiar with how things are set up for future lessons.

Intro to the Production Webpack Course

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](http://npm.im/webpack-validator), you can save yourself a ton of time by validating that your webpack configuration is free of common mistakes.

Note: Webpack 2 now has validation baked in.

Validate your Webpack config with webpack-validator

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. In this lesson, see how to take advantage of this awesome feature in Webpack 2.

Tree shaking with Webpack 2

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. In this lesson, we'll see how we can use the [polyfill.io](https://cdn.polyfill.io/v2/docs/) service to automatically polyfill this API (and others) for us.

Polyfill Promises for Webpack 2

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.

Maintain sane file sizes with webpack code splitting

Leveraging the browser cache is an important part of page load performance. A great way to utilize this cache is by versioning your resources. In this lesson, learn how to use Webpack’s hashing feature so you can take advantage of long term caching of your assets.

Hashing with Webpack for long term caching

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).

Grouping vendor files with the Webpack CommonsChunkPlugin

If you have a multi-page application (as opposed to a single page app), you’re likely sharing modules between these pages. By chunking these common modules into a single common bundle, you can leverage the browser cache much more powerfully. In this lesson we’ll use webpack’s CommonsChunkPlugin to easily share common modules between apps.

Chunking common modules from multiple apps with the Webpack CommonsChunkPlugin

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. In this lesson we’ll combine several webpack plugins to optimize things for a React application (this is also applicable for non-React applications as well).

Optimize React size and performance with Webpack production plugins

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](https://github.com/webpack/imports-loader) to provide those dependencies explicitly.

Expose modules to dependencies with Webpack

When you have a dependency that does not export itself properly, you can use the [`exports-loader`](https://npmjs.com/package/exports-loader) to force it to export the pieces of the file that you need.

Import a non-ES6 module with Webpack

There are several steps involved with setting up [`Karma`](http://karma-runner.github.io/) to work on your webpack project. In this first step we'll initialize our karma configuration and setup our `package.json` `scripts`.

Initialize a Webpack Project with Karma for Testing

[Chai](https://npmjs.com/package/chai) assertions work great with the [Mocha](https://npmjs.com/package/mocha) testing framework. In this lesson we'll walk through out to install Chai and [karma-chai](https://npmjs.com/package/karma-chai) so you can use the `expect` assertions in your tests.

chai

Use Chai assertions for tests in a Karma project

When writing tests run by Karma for an application that’s bundled with webpack, it’s easiest to integrate webpack and Karma directly together. In this lesson we’ll see how to utilize the [`karma-webpack`](https://npmjs.com/package/karma-webpack) plugin and reuse our existing webpack configuration to preprocess our test files with webpack.

Use Karma for Unit Testing with Webpack

How much of your code runs during unit testing is an extremely valuable metric to track. Utilizing code the [`karma-coverage`](https://npmjs.com/package/karma-coverage) plugin and [`babel-plugin-__coverage__`](https://www.npmjs.com/package/babel-plugin-__coverage__) plugin, we can get an accurate measure of how well we’re covering the files that we are testing.

Add Code Coverage to tests in a Webpack project

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. In this lesson we’ll learn how to ensure all source files are included in coverage reports and how to enforce a specific threshold so you can work toward improving application code coverage.

Ensure all source files are included in test coverage reports with Webpack

egghead

webpack v1 from Kent

https://app.egghead.io/api/v1/lessons/javascript-intro-to-webpack/subtitles

[00:03] To use webpack you need to npm install the Webpack module. You need to create a new file, webpack.config.js. Webpack will expect that this file exports the config and the config is very big and very customizable. But we're going to use a simple case here.

[00:25] We'll say module.exports is an object. You need to tell Webpack the start of your application, so the entry file, and the output file. We'll say entry is our index.js, and output is an object where the file name will be bundle.js and the path will be dirname. We can actually run this right now. It'll work fine. But our application isn't built to use Webpack right now.

[01:00] Let's just describe our application here really quick. We have this nice little background image. We have a couple of buttons here that have an event handler added to them via JavaScript. Then we have this DOM binding stuff. Which is another JavaScript file.

[01:24] All of this is brought in via script tags in our HTML, and we're also using lodash as a third party. What we want to do is we want to replace all of these script tags with a single script tag which will be bundle.js, so the output of our webpack, and we'll take all of these out.

[01:45] Then in our index.js, we're actually referencing these as globals. Here alert-buttons.js is global for alert buttons, and then the lame-dome-bindings.js is for this one. Instead we want to use a common.js syntax to require these where they're needed.

[02:07] Webpack is actually very powerful and it understands common.js, also AMD, ES6, and even globals. You have a lot of power there. But we're going to use common.js.

[02:22] First I'm just going to go based off of what we have here. Without changing anything, if I type webpack, it's going to run our config. We've configured it to output a bundle.js with the entry of index.js.

[02:37] If we look at our bundle, we'll see there's some webpack here for the monitor loading. Then it's just the, all of our modules. Because we only have this one entry and it's not actually requiring anything, there were no dependencies to resolve and so it just stuck in our, the contents of our file, and then it was done. We want to actually start to require things as needed.

[03:04] The first thing that you'll notice is it's wrapped in a function, so we no longer need the immediately invoked function, so we can take that out. Then we're going to say var AlertButtons is require alert-buttons. We'll do the same for the LameDomBinding.

[03:24] Now we're not depending on those as globals, but they're not exporting themselves as common js modules or any modules whatsoever. Let's go ahead and export those. We'll say module.exports for this one, and for this one as well.

[03:40] OK. If I run webpack, and we'll run webpack with a --watch, and I refresh here. Now it should be working but it's not, so let's look at what the problem is. Ah, reference error. _ not defined. You need to make sure that you're requiring everywhere because we're no longer depending on globals.

[03:59] The specific problem isn't in our alert buttons. We're depending on the global underscore. But because we're not actually sticking that script on the page anymore, we need to require that. We'll say _ is lodash. It works as common js so it's going to look up in our known modules for lodash. Now if I refresh, everything should work as expected. No errors in the console. Sweet. That's an intro to Webpack.

https://app.egghead.io/api/v1/lessons/javascript-intro-to-webpack/transcript

https://app.egghead.io/api/v1/lessons/javascript-webpack-loaders-source-maps-and-es6/subtitles

[00:01] To enable ES6 in your WebPACK config, all that you need to do is add a module and loaders property. In this loaders it's an array of objects. These are the loaders for the files that you require into your project. Each one of these load objects has a test property, RegEx, that will be matched against any files. Any files that match this RegEx will be loaded through the loader that you specify. 

[00:31] Here we're going to say anything that ends in JS is going to be loaded through BABEL, which is a loader that we need to install. We'll npm by BABEL loader. We install that loader. We want to exclude node modules because all of the node modules that we'll be using will be in ES5 so we don't need to run it through BABEL. We'll say, "Exclude node modules." 

[01:04] Now that's all that we need to do to enable ES6 stuff in our code, which is way cool. Let's go ahead and take our lame DOM binding. We'll double check and refresh. Everything is working. We'll change from common JS to ES6 module syntax. 

[01:22] We'll say, "Export default." Let's run WebPACK with watch. It's bundled. We refresh. Working way cool. This is really exciting. We'll also take this function and turn it into AeroSyntax and make it a one-liner just because we can. We'll even take this and remove the function keyword all together. Everything is totally still working, so I can still type which is way cool. 

[02:02] One thing that you need to be aware of when doing this is this bundle JS file is pretty big and not very useful. If we wanted to put a debugger in here and we refresh we get a debugger on there, but it's in that huge file. 

[02:22] Something that's really useful is using the DevTool property in here. In here you can say DevTool and specify a string. There are a couple options that you have in here, but a really good one for local development is eval. 

[02:38] WebPACK recommends this for development only. It's very fast to make the initial build, and rebuilds are very fast. If we refresh now you'd see this webpack://. We can see all of our source mapped files. That's what eval is doing. It's actually creating a source map for us. 

[03:04] If we look at the lame DOM binding here, then we can see the generated code as a source map. This isn't actually what I wrote. Remember it's a single line function. I'm not using module exports. If you want to have that, then instead you can say, "Eval source map." Then we'll rerun this. 

[03:29] It takes us a little bit longer to build initially. Then rebuilds are fast. This is also recommended for development only. Now if I refresh and open up my lame DOMbinding.JS you can see it's my code exactly as I coded it which is really neat. 

[03:55] You have that capability. If you're building this for actual production code, then you can use inline source map which is probably not exactly what you're going for. But this does allow for the same kind of stuff. You still get that source map power there. 

[04:19] If you really want this for something that's production, then you'll just use SourceMap. This will add a source map file for you, bundle that JS.map. That file is not actually loaded into the browser until the DevTools are brought up. 

[04:36] That is how you add ES6 to your project using WebPACK. You specify a module with loaders, and your loader tests for the file name that you want to have ES6ified. You give the loader a BABEL. You exclude whatever you want to exclude. That's all that it takes. All of a sudden you can use ES6 in all of your stuff, and it's awesome. 


https://app.egghead.io/api/v1/lessons/javascript-webpack-loaders-source-maps-and-es6/transcript

https://app.egghead.io/api/v1/lessons/javascript-webpack-css-preprocessors-and-url-assets/subtitles

[00:02] With Webpack's loaders, you can actually load more than just JavaScript. You can load a lot of different assets for your application. One of those assets that we're going to load is CSS. Right now, the way that we're getting CSS into our application is through the link attribute. Rather, the link element in our head.

[00:23] We want to modularize our application and load in the CSS that's needed, where it's needed. In our small, little app, that doesn't quite make as much sense, but in a large-scale application, it's really nice to be able to just simply require the CSS that's related to your component, whether that be in Angular, React, jQuery, or Ember, whatever.

[00:45] What we're going to do is we're going to remove the index.css. If we refresh, you can see now everything's gone. We're going to actually require the CSS for our application in our index.js. The way that this looks is you simply require. We'll say, "index.css." That's odd if you're used to Node CommonJS. You don't really commonly require stuff that's not just JavaScript files.

[01:19] Actually, we need to...Let's turn on Webpack watch here. If we refresh the page here, we don't actually have any changes because you can't find that module. We don't have a loader for that yet. We need to add a loader in our Webpack config. We'll do that here. We're going to apply this to all files that end in .css.

[01:47] We're going to load these through, actually, two loaders. One is called "style." The other one is called "css." This is how you pass assets through loaders. It flows from the right to the left. They're separated by the bang symbol.

[02:02] You have the CSS loader, which will read our CSS, and then you have the style loader, which will actually insert the styles into the DOM so that they're applied. We need to npm install those. Let's stop our Webpack here. We'll say, "npm i style-loader css-loader." We'll save dev.

[02:22] From there, everything should just work out of the box. If we say "webpack --watch" here, shouldn't get any errors. Looks like we did. Sorry. There is one other catch here. If we go to our index.css, we can see it's complaining about this line right here. The CSS loader doesn't handle this URL for us.

[02:54] We need to tell it how to handle that. We are going to have one more loader. It is the url-loader. We'll save dev. We're going to add to that as anything that ends in .png, any assets. In this URL, it will say, "Hey. I need to resolve this, webpack.png." We're going to say we want to resolve it with the url-loader.

[03:28] Now, if we run Webpack watch, there are no errors. If we go in here and refresh the page, everything is working as expected. All of our styles are applied appropriately. Actually, if you look here, before, it just had a background image pointing directly to that URL, but now you see it's just a data string, a base64 data string.

[03:57] This is actually really cool. Now, instead of having to ship your index.html and making sure that all of your assets are being passed up to the server properly and copied over and everything, you actually just need to ship this bundle.js because it contains your PNG images.

[04:17] There is a threshold. If your image is too big, then it will actually be bundled separately. In that case, you will need to send those up. This is also configurable, but this is really nice and simplifies things in a lot of really great ways.

[04:35] That is how you add the CSS loader. It's really cool. If we wanted to decide, "Hey. Let's use a preprocessor here. We'll change this to a less file," then all we need to do is pass this through our preprocessor for our less. We'll say, "npm install less-loader," and save dev.

[05:04] This is valid less. What's cool about less? We can say, "body." We'll wrap all of this in the body. Now we'll say, "webpack." One other thing. Obviously, we'll need to change this to less because we changed file name. Then we say, "webpack --watch."

[05:30] We are getting an error here. Obviously, we also need to change our test. This needs to change from "css" to "less." Now let's restart that. Everything should work here. Then we refresh. We've got everything. We have the power of less.

[05:47] It would be really easy to...If somebody decided, "You know what? I don't really like less very much. I'm going to use stylus," then we could add one for stylus. Boom. We have it. In fact, I'll just do that really quick.

[06:04] I don't know. We'll take the logo piece out. We'll put it in our own file, logo.styl. We'll turn this into a stylus happy thing without any of this, without those. Now this is valid stylus. Let's npm install stylus-loader. Save dev. Then, in our index.js, we'll require the logo.styl. We'll restart this. We have our new config. Everything's working. The logo is still there.

[06:48] We're running less and stylus together in a single project, which is probably not a terrific idea, but that just demonstrates how easy it is to have Webpack load all kinds of different types of assets for you. That is how you use Webpack to load your styles.

https://app.egghead.io/api/v1/lessons/javascript-webpack-css-preprocessors-and-url-assets/transcript

https://app.egghead.io/api/v1/lessons/javascript-add-a-browser-build-to-an-npm-module/subtitles

[00:00] So far, we've only considered node as a consuming platform for our module. There could be people who want to use our library in the browser. Right now, with the way that we distribute our file, we're depending on Require, which is CommonJS, which the browser does not support.

[00:16] We're going to add support for using our module in the browser. We're going to use something that's called UMD, or Universal Module Definition. To do this, we're going to use a JavaScript bundler called webpack. We'll install that as a dev dependency.

[00:29] Next, we'll create a new file called webpack.config.babel.js. The .babel allows us to write our webpack configuration in ES6.

[00:39] I'm going to go ahead and pre-fill this. We are importing join from path. We have this include being dirname and source. We're using that for includes on our loaders to run these loaders only on things inside of our source directory.

[00:57] Then, we have our entry as the index file. Our output will be in the dist directory. Our library target will be UMD, Universal Module Definition. It works in CommonJS, the browser, and AMD. Then, the context over browser, the library will be called starwars-names. You can get that off of the window object.

[01:20] Then, we have the source map dev tool so that we include source maps in our build. Now, because we're including the babel-loader and json-loader, we'll need to install those.

[01:32] Now, let's create our npm script for building these. We already have a build script. I'm going to rename this to build-main because we're going to have three build scripts. The next build script is going to be build-umd. Then, we'll have a third build-umd.min.

[01:51] For build-umd, it will simply be webpack --output-filename index.umd.js. It will be very similar for our min. The only difference will be we'll add a min here for the filename. We'll add the -p, which means run this in production mode. That will tell webpack to minify our code and optimize it for delivery to a browser.

[02:15] Now, if we run these scripts, we can run npm run build-umd. Let's check out our dist. We now have this UMD file. This is the Universal Module Definition function here. It has all of our code in there. We even have our json directory in here as a module export.

[02:36] Everything will work fine even in a browser. You'll notice also in this bundle that it includes the code for unique-random-array. Actually, unique-random-array has dependencies in that code as included as well.

[02:47] This is probably fine for a module like this one, but if you're building a plug-in for React or Angular, then you'll probably not want to bundle the entire library in your small module. You'll want to adjust your webpack configuration a little bit so that webpack excludes those things from the bundle, and instead requires those based off of the environment that it's in, whether it be global, or CommonJS, or AMD.

[03:14] That's something to definitely be aware of if you're building something that should sit alongside of another bigger library like React, or Angular, or Ember.

[03:25] Let's also go ahead and run our npm run build-umd.min. This will generate the minified version of this file optimized for delivery to a browser.

[03:38] Now, we have three scripts that we need to make sure we run before we do any releasing of our library. We're going to utilize a package called npm-run-all, which will help clean up our scripts a little bit.

[03:49] Install this as a dependency. With that installed, we'll add a build script that will utilize npm-run-all. It will run these in parallel because they are not dependent on each other at all. We'll run build:*. That will include build-main, build-umd, and build-umd.min.

[04:13] Now, we can run npm run build. Remember, we'll run our pre-build to remove the dist directory. Then, it will run this build script to run all of these build scripts in parallel.

[04:24] Now, we'd look at the dist directory. We have our index. We also have our starwars-names still. This can be consumed in a CommonJS scenario easily.

[04:34] Then, we have our UMD. This can be consumed in a browser, or in a CommonJS scenario, or in AMD scenario. Then, we have our umd-min, which is the same thing, just minified. That is what we need to do to support the browser.

[04:51] To review, there are a couple of things that we did. First, we installed webpack. Then, we created this webpack configuration. Then, we added json-loader and babel-loader as our dependencies. We also created a couple of scripts here.

[05:07] We changed our current build to build-main. Then, we added build-umd and umd.min. Then, we changed our build script to an npm-run-all script, which runs all of our builds in parallel.

[05:19] A final word about distribution. We're not actually committing these generated files to Git. People can't go to our GitHub repo and download these UMD files. Instead, we can point people to npmcdn.com where they can get these files.

[05:35] We can see an example of that here. If you go to npmcdn.com, you'll see the example of React. Here, they have the react.min.js. This is the entire React library.

[05:47] For our library, we could simply go to starwars-names. This is going to pre-load us with the default, which currently can't be consumed by the browser. When we actually publish this, people would be able to go to dist/index.umd.js. This will actually have the file that we're publishing to the registry. That's how people will consume our package if they're using the UMD build.

https://app.egghead.io/api/v1/lessons/javascript-add-a-browser-build-to-an-npm-module/transcript

https://app.egghead.io/api/v1/lessons/angularjs-angularjs-with-webpack-introduction/subtitles

[00:00] The first thing that we're going to want to do, obviously, is install Webpack. We'll also install webpack-dev-server. We'll install these as dev dependencies, so we'll add that -D. Then we'll create a webpack.config.js with a module.exports, our config object.

[00:22] We'll set our context to be the context of our application. This will be...Whoops. Need to spell that correctly. dirname plus /app. The context of our app is right there in the app directory. Our entry file is going to be index.js. That will be in relation to our context.

[00:45] We'll put our index.js there, and then we'll have our output, where the path is the same -- dirname plus /app. The filename will be bundle.js. That's it for our webpack.config. We're going to create our index.js here with an alert of "Hello."

[01:11] We'll run Webpack. This will create the bundle for us. In our index.html, we'll add that bundle as a script, where the src is bundle. We save. If we refresh, we get the "Hello" there. We're going to actually delete this bundle, the file, just to illustrate something here.

[01:38] Instead of using Webpack, we want to have a server that will automatically rebuild every single time. We can accomplish this same thing with Webpack watch, but we're going to use webpack-dev-server instead.

[01:52] I recommend in your package.json, you'll add a script called "start," where it points to the webpack-dev-server in your local known modules, with a content base pointing to your context or where your app will be served up.

[02:10] With that configuration, if I say "npm start," it will run that script for me. Now it's serving up my app on port 8080. If I switch this to localhost:8080, I get the "Hello." Now we're running using webpack-dev-server.

[02:28] Again, you'll notice that the bundle.js is not inside the app directory, but it's still running. That is because webpack-dev-server is actually serving that file in memory. When a request comes for that bundle.js, it will send that file to us instead.

[02:47] Now let's make this an Angular app. The first thing we'll do is we'll say, "ng-app="app." Inside of our index.js, we are going to require dependencies a little bit different than you may be used to. The first thing we'll do is we'll npm install angular, and in here, we'll say, "var angular = require('angular')." That's common JS syntax that Webpack enables us to do.

[03:16] We'll create our app module with no dependencies. From here, everything should work if I assign this to ngModule and then say "console.log(ngModule)." Save, refresh. In here, we have our object, which is our module. We also have the Angular logo up there. This is an Angular app.

[03:44] Everything is up and running with Webpack using this configuration here, where the context is pointing to the app directory where our app is living. We have an entry of our index.js file, and then our output is pointing to the same directory and a bundle.js file. In here, in our index.html, we're referencing that bundle.js file.

[04:15] That is how you get started with Angular and Webpack. More to come.

https://app.egghead.io/api/v1/lessons/angularjs-angularjs-with-webpack-introduction/transcript

https://app.egghead.io/api/v1/lessons/angularjs-angularjs-with-webpack-requiring-directives/subtitles

[00:01] Now we're going to add a directive to our application here. So what we're going to do is we'll create a new file in directives/index.js. In here, this is going to represent the folder, and so this folder can be required because we have an index.js. In here what we're going to do is say module.exports equals function that takes an NG module. We'll use that NG module to register the directives that are in this folder.

[00:32] The first thing that we'll do inside of this directives folder is create a kcd-hello.js file, and in here, this will also export a function, so we'll say module.exports = function(ngModule), and we'll say ngModule.directive kcdHello that's a function that returns our DDO. Return and this will be a component directive, so we'll restrict as an element. We'll make it use isolate scope, we'll have a template URL that points to directives/kcdhello.html, and then we'll also use controller as VM, controller will be a function here.

[01:20] We'll see var VM = this, and then vm.greeting = 'hello Webpack'. So now we need to create our template, so kcd-hello.html. We'll make a div that has a class kcd-hello, and in here we'll just say vm.greeting.

[01:40] Now our directive's all wired up. We need to tell our module about this directive, so inside of our app index where we create our module in the first place, we're going to require the directives folder. If you remember in our index.js this exports a function that accepts an NG module, so let's say NG module, and in here, we're going to require the kcd-hello directive and pass it the NG module. Now this is a very modular approach, because we're not using the angular.module getter all over the place.

[02:24] We're passing the module where it needs to go so that things can be registered on it. That makes things a lot more modular in the sense that you can move things around, have them be registered on totally different modules, and you don't need to worry about changing the module name that something is being registered on it, just has an API that accepts the module.

[02:48] Let's go ahead and look at our template, our index, and let's use our kcd-hello to make sure everything is working. If I save and refresh we should get Hello Web Pack, we did, so everything is wired up together and just in review, you have in our Webpack config our entry is index.js, our context is this app folder, and o when we go to that index.js we require angular, and we create the angular module, then we pass that angular module to our directives which will pass that module on to all the directives that are in this folder.

[03:30] Each one of those directives, in this case just one, will register itself with that module. Then in our template, we have access to that directive. That is another step on the path to using angular with Webpack.

https://app.egghead.io/api/v1/lessons/angularjs-angularjs-with-webpack-requiring-directives/transcript

https://app.egghead.io/api/v1/lessons/angularjs-angularjs-with-webpack-requiring-templates/subtitles

[00:01] When you're using Webpack, you have a really huge benefit that comes with all of your resolve statements being executed before your files are loaded into the browser. One thing that is insanely powerful is instead of using templateUrl, you can use template everywhere.

[00:18] You don't need to worry about the templateCache or XHRs firing off to go get your templates. The way that this works is you simply require the file there. You're done. You do need to add a loader, but what's really nice about this is this makes things a lot more modular.

[00:36] We could move these two files anywhere together. This component would still work. We wouldn't have to change the templateUrl to be pointing to the correct place wherever you move the file. This is a huge win that Webpack gives us.

[00:50] If we were to save this and refresh, we're going to get an error right here. You need an appropriate loader to handle this file type. Webpack doesn't understand what on Earth this is talking about.

[01:01] To accomplish this, we need a new loader. We'll npm install the raw loader. We'll add that as a dev dependency. We'll go to our Webpack config. We'll add a new loader here. Anything that ends in an HTML, we want it to use raw or the raw loader. Pro tip. This and this are the same thing. If you don't want it to be so verbose, then you just leave off the "loader."

[01:32] Now, if we restart our dev server, everything should work properly. We refresh. Everything is good to go. You no longer need to use templateUrl or template anything. In fact, with something so simple as this, we don't even need to reference that. Because this application is using ES6, we could just as easily put our template right there. No worse for wear.

[02:00] It depends on your style. Obviously, you're not going to want to do this if your template is very large, but as it is, it works really well just to use the template string with the backticks so we have multilines. That is loading your HTML, getting rid of your templateUrl, and just using template.

[02:23] This really resolves a lot of the concerns with the HTTP backend when you're testing to make sure that you're loading stuff with ng-to-JS HTML loader plugins for Karma or whatever. You don't need to worry about that anymore with Webpack. That's another awesome thing that Webpack brings to the table with Angular.


https://app.egghead.io/api/v1/lessons/angularjs-angularjs-with-webpack-requiring-templates/transcript

https://app.egghead.io/api/v1/lessons/angularjs-angularjs-with-webpack-es6-with-babeljs/subtitles

[00:00] The next thing we want to do in our application is we want to start using ES6 features today. We're going to do that with a library called Babel. There's a webpack loader for this library.

[00:12] The first thing that we'll do is we'll MPM install the Babel loader, save that as a dev dependency. And then, inside of our webpack config, we'll say module, loaders, and we'll test for all files that end in .js. For all of those, we'll apply the loader Babel.

[00:36] Now we need to restart our webpack Dev server, MPM start. In our index.js, just to make sure that everything is working, we'll change this to const. We'll save, refresh, and everything is working.

[00:52] Let's go ahead and change a couple of things to ES6. We'll say export, default, changes this to an arrow function. Everything's still working. We're good. We'll do export, default, change that to an arrow function. Everything is working.

[01:13] Just for the fun of it, we can change these to arrow functions, as well. We're going to be kind of crazy here. Yeah, that would be a bad idea, actually. Don't do that. In fact, I'll show you why.

[01:26] If you do, then this is bound to the lexical of this. So doing this is actually this being compiled down to something that looks like this and this. That's why you don't want to just go crazy using arrow functions all over the place. It's wise to only use them where it makes sense.

[01:50] It's important to know how arrow functions work, just like all JavaScript. We're going to change this back to a function, fix this back to this, and move that. Now everything is up and working. Just be aware of a couple of tricky things with ES6, but yeah, we can use ES6 features in our Angular code. Super, super easy.

[02:15] That's ES6. All that you really need to do is webpack config, loaders. Everything that ends in .js will be loaded through the Babel loader. If you want to, you can also include an exclude node modules, so that none of your dependencies will run through the Babel loader.

[02:35] We'll restart our server, refresh, and everything is still working. That's how you do ES6 with Angular.

https://app.egghead.io/api/v1/lessons/angularjs-angularjs-with-webpack-es6-with-babeljs/transcript

https://app.egghead.io/api/v1/lessons/angularjs-angularjs-with-webpack-requiring-css-preprocessors/subtitles

[00:01] Now let's say that we want to style this directive. Say we want to change the color of the text, for example. Normally, what you would do is you'd create a file called "kcd-hello.css." We'll look at our template. We have the kcd-hello class. We'll say, "kcd-hello," "color." We'll just say it's green.

[00:22] If I save this and refresh, obviously, it's not going to be applied because this kcd-hello is not being loaded into the browser. Webpack is really cool in that you don't have to build all of your assets separately and then make sure that you deploy your styles.css and scripts.js and all of that.

[00:39] Instead, you just deploy your single bundle.js file. That will load everything that you need, including images, in most cases. What we're going to do is we'll just require all the things. Right here, in our directive definition, we're going to require kcd-hello.css.

[01:02] If we save this and we look at our output, we're going to see unexpected token. We've got problems right here. We need to load the appropriate loader for this file type. The appropriate loader is...Actually, there are two of them that we need.

[01:17] First, we need the CSS loader. That's going to give us the ability to read the CSS file, know what it means, and turn that something that the style loader will understand. The style loader will actually load this as a style tag, into the browser.

[01:32] We'll npm install, as a dev dependency, css-loader and style-loader. Now we're going to need to restart our Webpack server, but let's create our loaders first. We have our stuff for JS, HTML, and now CSS. Add our comma there. Our loader will now be style and CSS.

[02:05] Loaders run from the right to the left. First, our files will be run through the CSS loader. Loaders are separated by a bang symbol. Then it'll be run through our style loader. This will be applied to any file that matches .css.

[02:21] If we go back here, this file matches .css. This will be loaded through the CSS loader and then the style loader. Let's npm start to start our webpack-dev-server, and then we'll refresh. You see it's green. That's exciting. We're actually getting the styles in here. Let's look at the DOM and see what's actually going on here.

[02:44] We have this new style tag that we didn't have before, that has a kcd-hello color green. Just to be sure that we're not crazy or something, we'll change this to red. We'll save and refresh. Now that's color red. That is what's actually happening as these styles are getting loaded into the browser.

[03:03] Lots of times, you're going to want to use a preprocessor for your CSS. If that's something that you're wanting to do, you're going to need to have yet another loader. Let's add a new line here. We'll use stylus in this example. We're going to add one more loader, the stylus loader.

[03:26] The stylus loader will take a stylus file, convert it into CSS. Then the CSS loader will take that, convert it into something that the style loader can understand and inject into our DOM. We need to, obviously, install the stylus loader. We'll npm i -D stylus-loader and make sure that installs properly.

[03:50] Then we'll need to restart our Webpack server. We refresh. Everything's still working because we're still using this CSS here, but let's change this from CSS to styl. Then we'll change this into some stylus goodness here without all of that other stuff.

[04:12] There are times that you may need to restart your Webpack server just because it doesn't recognize file name changes in some cases and things. If you don't see this change from valid to invalid when you change a file, like that, then you've got a problem.

[04:26] You need to restart your Webpack server. We'll go ahead and restart it. We'll refresh. We are now getting an error. This error is coming because when we changed this file name, we forgot to change how we're requiring it. Here, we will require the styl file.

[04:44] Now we'll refresh. There, we have "Hello Webpack" in red. We can change that to green, just to make sure that everything's working. Now we have stylus. If we wanted to change that to less, we'd just change this to less, change this to less, and then, obviously, install the less loader.

[05:05] We'd change this file name to be less and, obviously, require it as a less file, and then change the syntax because less doesn't understand stylus syntax. That is how you include your CSS into the browser.

[05:21] In our case, we don't need this CSS loader or test case anymore. We have no files that match that, but we'll just leave that there anyway. That's how you have a specific style for a specific component. Again, all of these files live together. 

[05:41] It makes things much more modular than the traditional thing that we're all used to, where we have different things being loaded from different directories. It's just a big mess. Everything is all together and makes things a lot easier to move around as architecture decisions change. That is using CSS with Webpack and Angular.

https://app.egghead.io/api/v1/lessons/angularjs-angularjs-with-webpack-requiring-css-preprocessors/transcript

https://app.egghead.io/api/v1/lessons/angularjs-angularjs-with-webpack-testing-with-karma-mocha-and-chai/subtitles

[00:00] Testing with webpack in Angular takes a lot of setup, but once it's all set up, it's actually very easy and nice to work with. The first thing that we're going to need are a lot of dependencies.

[00:11] We're going to npm install dev dependencies. First, we're going to use the karma runner, so I'll use karma. We'll also use karma-chrome-launcher, because we're going to use chrome. Then we're going to use karma-webpack. We'll also be testing with mocha and chai. That's all that we're going to need for testing in our Angular application.

[00:30] Now let's go ahead and initialize our karma config, so karma init. We're going to be testing with mocha. We are not going to be using require. We are using chrome. We are not going to be specifying any files or excludes files. We'll do that a little bit differently. We will just go ahead and let it watch.

[00:49] Let's open this up. This is pretty standard. We're going to add a couple of things here. We'll say plugins, and we're going to require the webpack, or rather karma-webpack plugin. Then we're also going to use the karma-chai and karma-mocha and karma-chrome launcher plugins. That's simple enough.

[01:15] Now we're going to want to tell karma what files to load. With webpack, things are a little bit different in that, what's loaded into the browser is a bundle that's generated by webpack. Because we're using the karma webpack plugin, we're actually just going to specify the entry for our webpack config.

[01:37] The way that we get that is we'll just get our webpack.config straight from webpack.config.js. We'll say require webpackConfig. This will come from webpack.config. We're going to get our entry, and this will actually come from the webpack.config, but we're going to need the path, module path, path.

[02:04] Because if we look at our webpack config, we have our entry, but this is in respect to the context, so we need to resolve those two together. We're going to say path.resolve, webpackConfig.context, and webpackConfig.entry. That is our entry file, and that is the file that we're going to be telling karma to load.

[02:25] We also need to specify our webpackConfig, and so we'll just give it our webpackConfig there. Then finally the preprocessors is one other thing that we need to specify, and this is very important. We'll say var preprocessors is an object, and then preprocessors for the entry file will be webpack.

[02:46] That is our karma config. We have our plugins. We specify our preprocessors as an entry for webpack. We also specify the files as being our entry, and then we specify our webpackConfig as being the same as the webpackConfig here.

[03:05] There's still yet more to do. One thing that in an Angular application that you need to do is you need to have the angular-mocks so that you can load the correct module and you have some other helpers there. We'll npm install, save as a dev dependency, angular-mocks. That installs.

[03:24] Now we need to actually include that. Because we're just using our index.js, we need to include it in here. What you would normally, if you were just thinking about this, you would just say require angular-mocks/angular-mocks.

[03:40] The problem that you have here is now you're loading angular-mocks into your production code. If so, if you were to deploy this, angular-mocks would run, and that would be a problem from a couple of standpoints.

[03:51] What you really need is to have something like this. Now this will only be loaded into the browser if we're ON_TEST, and webpack is smart enough to know that if this code will never run, that it doesn't actually resolve that require.

[04:09] What we need to figure out is how to get webpack to say, "Hey, this value is false in certain contexts." That is very easy to do using the define plugin. In our webpackConfig we're going to get webpack, and we're going to add plugins. It's an array, and we'll say a new webpack.DefinePlugin. This is an object of all of the variables that we want to have resolved to actual values in our code.

[04:43] We have this ON_TEST, and we're going to say process.env.NODE_ENV is equal to test. In the case that that is true, this will be evaluated to true, and this require will evaluate. In the case that that's false, this require will be ignored and [indecipherable] when we ship it to production we'll actually just totally remove all of this code anyway, so that's not a problem.

[05:10] Now we're loading angular-mocks, but we don't have any tests to run yet, so let's go ahead in our directives. We're going to test this kcd-hello directive. kcd-hello.test.js. In here, we're going to describe kcd-hello, and...

[05:33] One thing that's a little bit interesting is part of what we're trying to accomplish here is we never want to use the angular.module getter. That encourages modularity, and so we can move things around without having to worry about the names of modules or anything like that.

[05:50] If we follow what we're doing currently where we have this directives with the index. It's a function that accepts a module and then it passes that onto the kcd-hello directive.

[06:03] What we want to do, the API we're looking for is something like this. If ON_TEST, then we want to require the kcd-hello.test. This is modular because anytime we move these files, we want them to stay together so they're together. That keeps things a lot cleaner and easier to reason about. What we're looking for is something that we can pass the ngModule into so that it knows what module to register for the test.

[06:38] Let's go ahead in our kcd-hello and we're going to take this and create an export default ngModule. This is a function that takes in ngModule. Then we'll use that to describe our test. Before each, we're going to say module, ngModule.name.

[07:03] There's a problem here. In common JS land, where we're living now, module actually has meaning. We need to specify this on window.module so that we're referencing the module that angular-mocks creates. Now we can give our it. It should test properly. Then well just give ourselves a failing test. We'll say expect false to be true.

[07:31] If everything works properly, what we need to do in our console when we actually run these tests is we'll say NODE_ENV=test. Then we'll say karma start. If everything runs properly, then we'll get a failing test. There we go, expect is not defined. I believe that I know the reason for that. If we go to karmaConfig, we need to specify our frameworks as chai so that we get expect on the global.

[07:58] Let's restart this. We should get a failing test now. Expected false to be true. If we go back to our hello.test, expected true to be true. Now we have a succeeding test. That's how you test everything. Everything's all set up for this to work and it scales very well.

[08:19] In review, you take your karmaConfig and you alter it in a few small ways beyond what you would normally do in a regular karma configuration. You need to determine your entry via your webpack context and entry. Then you assign the preprocessors property of that entry to the webpack.

[08:44] Then as the files that are loaded into the browser is entry. You also specify the webpackConfig in your karmaConfig. That's pretty much all that's different from a regular karmaConfig that you would have in any other Angular application.

[09:01] Before any of your tests are registered, you need to load in angular-mocks, because they depend on the window.module. I'm doing it this right after we require Angular in our entry file, and then we create our module, and then we require all the directives, and in the future other things that we need for this module.

[09:23] We pass in the module, and when we're ON_TEST, we're going to require the test where we pass the module and that module is used to load the module before each test. From there, everything works as you would expect from a regular Angular test where you use the compile and whatever else you need to test these functions and these directives. That's how you set up tests with webpack.

[09:51] Sorry, one other thing. Because I'm not a fan of typing all of that in your package.json, it's a good idea to have a script for test. We can just say NODE_ENV=test, and then karma start. Now in here I can say npm run test. That will start my test for me, and I don't need to worry about the proper options or anything else I need to pass in. That's webpack with Angular and karma testing.

https://app.egghead.io/api/v1/lessons/angularjs-angularjs-with-webpack-testing-with-karma-mocha-and-chai/transcript

https://app.egghead.io/api/v1/lessons/angularjs-angularjs-with-webpack-production-setup/subtitles

[00:02] We've this really awesome application. Let's go ahead and take a look at this. If we go to our local host, this is what we see Angular + Webpack, Hello Webpack in green. How awesome is that? We've got to deploy this out to the world. What we're going to do is we're going to modify this configuration if we're in production mode so that we can ship this off like a real production app.

[00:24] The first thing that we're going to do is let's take a look at our package.json. We already have this built script in here that sets the node environment to production so that we can tee off of this node environment to know how we need to modify our webpack configuration. We're copying the index.html to our "Dist." The dist is the folder that we're going to be distributing to our production application.

[00:46] Let's go ahead and respond to the node environment being production and send our bundle to the dist directory as well. In our webpack config, we're going to say "Var config equals that webpack config" that we had in the first place. At the bottom, we'll say module. module.exports equals config.

[01:02] We're going to modify this config if we're in production mode. We'll say, "If process.env.node_env equals production," then we're going to modify our output path. We'll say, "Config.output.path is now equal to dirname plus dist."

[01:25] Now, if I run npm run build, it will set the node environment to production and run our webpack configuration. Now, we can see we have a dist that has the index that was copied over and our bundle.js. If I just simply run an HTTP server over our dist, we can now look at local host 8080. This is being served up from our dist and the whole app is working great.

[01:51] That's how you modify your configuration for webpack for production deployment. You simply specify your node environment to production. You respond to that node environment inside of your webpack configuration.

https://app.egghead.io/api/v1/lessons/angularjs-angularjs-with-webpack-production-setup/transcript

https://app.egghead.io/api/v1/lessons/angularjs-angularjs-with-webpack-uglifying-your-javascript/subtitles

[00:00] Now we have our application building to our DIS directory where we can send off all of the resulting files of our application. Let's go ahead and run an http-server on that DIS directory just to see what we have here.

[00:13] If we look at our source for this page, we have this "bundle.js." We look at that bundle, and it's this huge file full of comments and white space that we're sending down to the client for no reason at all. We need to minify this JavaScript to make the payload of this JavaScript file as small as possible.

[00:29] Webpack makes this extremely easy, but there are some considerations that you need to take into account when minifying JavaScript in an Angular application. The first thing that we're going to do is when we're inside of this "Production environment," we're going to add a plugin to minify our code.

[00:46] We'll say config.plugins.pushanewwebpack.optimize.uglifyjsplugin. There are some options that you can pass in here, but we'll omit those for now. Now if we run npm run build, this is going to take a second longer. The reason for that is the uglifyjs plugin is uglifying not only our JavaScript but also Angular and any other definities that we have.

[01:14] The result is a minified JavaScript file where, if I go ahead and run our http-server DIS, I refresh this page, everything is working. Then if I look at my bundle.js, it's much smaller. This is optimized for delivery to the web.

[01:32] The problem here, though, is if I were to go into, say, "My app directives" here and if KCD Hello had something that it required -- let's say it requires log and then in here we say "Log.info I have some info" -- now if I run my build again it's going to uglify all this stuff. If you're familiar with this problem, you know exactly what's going to happen. Let's go ahead and serve up our resulting stuff.

[02:08] Everything is broken. If we look at the console here, unknown provider T provider, this is awful. The way that we overcome this is by using "Annotation." Just to make this a little bit easier, we're going to change this back from an arrow function to a regular function.

[02:26] In Angular you need to annotate your functions. You can do that a couple different ways. One way is you could say "Log" and make that array. Angular will know what to inject for you. If you don't do that, when the uglify.js plugin goes through, in our case it changed that to a T to make it as small as possible because in JavaScript the name of the parameter doesn't matter.

[02:52] Only in Angular does the name of the parameter matter. That's using the implicit dependency injection. We need to be explicit about our dependency injection. We'll use the ng-annotate plugin to do that. Webpack has an ng-annotate loader that we're going to be using. Let's npm install as a dev dependency the ng-annotate loader.

[03:17] Then inside of our loaders here in the JavaScript, we're loading it through Babel. Then after that we're going to run it through ng-annotate. Now if we run npm run build if we refresh this -- and we need to run our http-server on the DIS directory -- everything is working.

[03:43] If we look at our bundle, let's see if we can find where this dollar log is located. Here we go, KCD Hello. We have this explicit dependency injection in our function. That's being done by the ng-annotate plugin. In most cases you just need to plug this in, and everything will work.

[04:05] There may be some cases where you need to explicitly say that your function needs to be annotated. If you were to do that in our controller, for example, you'd simply add a comment here that says ng inject, and ng-annotate will say, "Oh, OK. I need to make sure that I annotate this function."

[04:25] That's how you uglify your Angular code using Webpack. In review you simply add the Webpack optimize uglify JS plugin. Then you install the ng-annotate loader and add that to the loaders for your JavaScript files.

https://app.egghead.io/api/v1/lessons/angularjs-angularjs-with-webpack-uglifying-your-javascript/transcript

https://app.egghead.io/api/v1/lessons/angularjs-angularjs-with-webpack-production-source-maps/subtitles

[00:00] Now that we have our app running in production, let's say that there's a situation where something breaks and we need to debug in production. Worst nightmare ever, especially when you don't have source maps built into your production app. It's very highly recommended that you enable source maps for your webpack configuration, because trying to debug this would be a total nightmare.

[00:21] Let's go back to our webpack config. In production mode, we're going to say config.devtool equals source map. Then if we rerun npm run build, it's going to do our uglification and create our source maps for us. Let's go ahead and take a look at our dist. We now have a bundle.js.map.

[00:43] Our bundle.js will tell the browser, "When the devtools are open, I want you to load this, and source map file." Let's go ahead and serve up http-server on our dist. If we refresh here, now we have this webpack://. Our source maps are in here, so we can look at our directives, KCD Hello.

[01:08] We have source maps, and so we can add a breakpoint here. There I can take a look at the context of where I am, and debug much simpler. One thing to note, however, you are actually running minified code, and so I can't simply say, "VM," to get this VM reference here.

[01:27] There is a little bit of that difficulty there, limitations with the browser, but for the most part, this is so much easier to read and reason about what's going on. You can step through your application logic, and understand what's going on. To add source maps to your production build, you simply set the devtool to source map, and it will add the source map file for you.

https://app.egghead.io/api/v1/lessons/angularjs-angularjs-with-webpack-production-source-maps/transcript

https://app.egghead.io/api/v1/lessons/tools-intro-to-the-production-webpack-course/subtitles

[00:00] In this course, we're going to be dealing with Todo's MVC application. It's based off of the Vanilla JS implementation and has been ported to ES6 and Webpack. In this lesson I'm just going to take you through a brief overview of how this application is put together, because lots of the lessons in this course will be dependent on some of these things that are already pre-set up.

[00:20] Here's our Webpack configuration file. We are using Webpack 2. This is actually a function that accepts an environment object and it returns our Webpack configuration object. We have our entry here, which resolves to our app.js file, which is in our source directory right there.

[00:42] Our output will just simply go to our dist directory with the filename of Bundle. The context for our application is the source directory and we have two types of files that we're loading -- first the JS files and the CSS files. The JS files are being loaded with ESLint and then in Babble. The CSS files are loaded with the CSS loader and then the style loader.

[01:05] We have a couple of scripts that we're using. First we have Build, which will build the development version of our application, and then Build Prod, which builds the production version. Here we're specifying the EMV as dev or our development build, and the EMV is prod for our production build. We're also passing this -p flag to tell Webpack to operate in production mode.

[01:31] We'll often use the Start script, which uses the Webpack Dev Server, specifying the environment as Dev, and the content base as the dist directory. We have a pre-start, which we'll run clean and copy script, which deletes our dist directory, with this Clean Dist script. It will copy the necessary files to our dist directory.

[01:54] We have a source Index HTML and a source favicon that will go into that dist directory. We also have tests in this project, so we have a test script with Karma Start. We also have watch test, which will run that in Watch mode.

[02:11] That's the overview of the project. I hope you enjoy the course.

https://app.egghead.io/api/v1/lessons/tools-intro-to-the-production-webpack-course/transcript

https://app.egghead.io/api/v1/lessons/tools-validate-your-webpack-config-with-webpack-validator/subtitles

[00:00] There's an error in this config file. Go ahead and take a look and see if you can figure out what it is. If we run our build, we're going to get an error that is all together helpful. We simply get, "You're going to need a loader to handle this type of file." It's not helpful what the actual problem is. It looks like it's having a hard time loading CSS.

[00:20] If we look in our config, we can see, no. We have loader specified. What the problem is, is we have this modules which actually should simply be module. If we run the build again, then everything is going to work out just fine.

[00:35] It can be really frustrating to have these kinds of issues. Typos are common. There's a tool called webpack-validator that we can use to validate our configuration to ensure that there aren't any typos like this, and give us a little bit more of a helpful error message.

[00:50] Let me go ahead and add that mistake back in there. We'll save that. We're going to go ahead and run npm-install --save-dev webpack-validator. It's notable that webpack-validator actually does a lot more than just typo checking. It will ensure that the types that you're providing are correct and a myriad of other things specific to your webpack configuration that are useful. I definitely recommend that you use it.

[01:14] Now with that installed, we can go to our package.json, and we'll see that webpack-validator has been installed in our project. We're going to make a validate webpack script. Here, we'll do two versions, because there are actually two versions of our build, the dev build and the production build. If we run validate webpack:dev, we're going to use the webpack-validator binary that has been installed for us.

[01:41] Then, we'll specify our config, so webpack.config.js. Then, to make sure that we're simulating the same environment that our regular build, our development build environment is experiencing, we add the --env.dev.

[01:58] That will run our webpack config with that proper environment set. We'll be getting the webpack configuration for development. If we save that and run npm run validate webpack:dev, then we're going to get this handy error, "Modules is not allowed." That gives us exactly the place where we have the problem. We can go look up in the docs and find out that modules should actually be module.

[02:25] Let's go ahead and add another one of these, one for production. Then, we can run the prod version to make sure that we're getting the same error there. Finally, we want to add these validations to our validate script which we currently have running as a pre-commit hook.

[02:44] We'll go ahead and use npm run all, their API, which we simply can say the name of the script to validate webpack:* and that will run all of the validate webpack: scripts that we have. Now, if we run npm run validate, we're going to get that error twice, once for each validator.

[03:06] Let's go ahead and fix this problem, change this back to module. Then, if we run validate script again, we're going to get that the config is valid, because this is the validate script that's also going to run our test and linting. Now, everything has passed just fine.

[03:25] In review, all that we need to do to add webpack-validator is install it as a dependency. Then, we can use the webpack-validator CLI that it comes shipped with to validate our webpack config, providing the same environment that's used for our build and prod builds of our library over our application in this case.

[03:47] It's notable that there's also a node interface to webpack-validator where you can require webpack-validator, and then we could simply wrap our configuration inside of this. Because we're using the CLI already, I'll get rid of all this. That's how you use webpack-validator with webpack 2.

https://app.egghead.io/api/v1/lessons/tools-validate-your-webpack-config-with-webpack-validator/transcript

https://app.egghead.io/api/v1/lessons/tools-tree-shaking-with-webpack-2/subtitles

[00:00] One of the aspects of ES6 modules is that they're statically analyzable. This means tools like Webpack can predict exactly which exports are used and which are not. Webpack takes advantage of this with a feature called "treeshaking." This feature can seriously reduce bundle sizes in large applications.

[00:15] Let's take a look at our helpers file here, we have this function addClass down here below. The only place the function is being used is in the app.js file, meaning that if we removed it from the app.js file, it's no longer needed in our bundle.

[00:28] Let's go ahead and do that, and now, we can open up our app, everything is still working. But if we look in thehelpers.js file, we see the addClass function is still being exported.

[00:39] That's to be expected, because we're still exporting this from the helpers file, and Bable is transpiling our ES6 module exports into common JS exports. Because this is getting transpiled down to common JS, it's not statically analyzable like ES6 modules, and so, Webpack can't reliably treeshake this function, and our bundle will include it even though it's not in use.

[01:02] We're going to use a different Bable preset, which excludes the transpilation of ES6 modules and leave that to Webpack.

[01:08] Now, let's install Bable Preset ES2015 Webpack, and now, if we open up our bable.rc file, we'll trade out the ES2015 with ES2015 Webpack preset, and then, just for the sake of completeness, we'll go ahead and get into our package.JSON and remove the original preset, because the Webpack version of this preset will have all of the other transforms that we need. We'll save that, and now, we'll run npm start to start up our application.

[01:38] This will automatically refresh, and now, we'll see that the helpers file is a little bit different with regards to how these ES6 module exports are transpiled. Before it was pretty straightforward common JS. Now, it's a little bit different because Webpack is going the transpilation for us.

[01:55] Because Webpack has an understanding of all the modules throughout our system, it realizes addClass is not being used anywhere in our application, and so, it adds this comment, "Unused harmony export addClass," and it excludes it from the list of things that are being added to our common JS export.

[02:13] You'll notice though, that the addClass function is still being added in here, but because it's not being referenced, when we go ahead and uglify our code using the uglify.js plug-in, this function will be automatically removed.

[02:25] We can verify that by running our production build. To do this, we can run NPM run build prod, which as you can see, is running node emv production Webpack with the -e flag, and if we scroll up here, we'll see this warning from uglify.js, "Dropping unused function addClass."

[02:42] Because that addClass function is not being referenced in any of the code inside of the helpers file, it's being dropped from our bundle, and we're not shipping that unused function to browsers.

[02:52] This applies to more than just our application code, this would apply to any ES6 module that we're importing into our application, including third-party dependencies.

[03:01] In review, all we had to do to leverage treeshaking with Webpack 2, is to install Bable preset ES2015 Webpack so that Bable doesn't transpile our ES6 modules, and then, we update our Bable.rc file to use that preset instead of the Bable preset ES2015 module. That's how you leverage treeshaking with Webpack 2.

https://app.egghead.io/api/v1/lessons/tools-tree-shaking-with-webpack-2/transcript

https://app.egghead.io/api/v1/lessons/tools-polyfill-promises-for-webpack-2/transcript

https://app.egghead.io/api/v1/lessons/tools-maintain-sane-file-sizes-with-webpack-code-splitting/subtitles

[00:00] We've added a list of animals to our app. Click on each one, and it shows us an interesting fact about that animal. Click outside of the animals, and we'll get a default message. These facts come in individual files, but they're all loaded into the bundle with this import statement.

[00:15] For the purposes of our example, let's imagine that we have thousands of these. We prefer to load these on demand, rather than have them included in the bundle.

[00:23] We'll start off by getting rid of this import statement, and then, we'll go down here. Instead of setting the inner text right there, we're going to use the ES6 system api to import this module.

[00:33] This will return us a promise. We'll add a function called a "setFactText" that will take the result of this module import, and set the FactText for us. Now, we don't have the dynamic facts implemented yet, but let's go ahead and take a look at what this looks like in the browser now.

[00:49] If we refresh the page, we'll see that we're loading the bundle. If I load the default message, then, we see this 1.bundle.js which is loaded. That is the module that we just imported using the system api. Webpack has a runtime for us, so we don't have to worry about loading that ourselves.

[01:06] If we try to load the other ones, we're going to get an error in here, Facts is not defined. Let's go ahead and dynamically load the animal Facts. To load these, we could have a big switch statement, or if statement of some kind to check what the Fact is that we're looking for, and system importing that one.

[01:23] That would be really tedious, and not scale very well to our thousands of Facts that we're going to be adding to this application. Instead, Webpack is intelligent and will create a bundle for us for every possible combination or dynamic import like so.

[01:39] Let's go ahead and look at the browser now. As we click around, we'll see that the different bundles created for each one of this is loaded dynamically on the fly as needed. Let's go ahead and take a look at the output bundle. We open up our terminal here, we run npm.run build, and then, we go to our isDirectory.

[01:58] We'll see there's a bundle for each one of these dynamic modules. We open up one bundle, we'll see the bundle for the default Fact, we open up 2.bundle we'll see the ostrich Fact, and so on and so forth.

[02:10] Webpack creates these dynamically, and we don't have to concern ourselves with them at all. We only have to make these available to Webpack, at the time our application starts running.

[02:18] While this scenario is a bit contrived, the basic concept is extremely practical and powerful. For example, here is some code that we could write to lazy load parts of React application using React Router, and Webpack's code splitting. It's using the same system api, and Webpack is able to load entire sections of the application as needed.

[02:36] That's how you use code splitting with Webpack.

https://app.egghead.io/api/v1/lessons/tools-maintain-sane-file-sizes-with-webpack-code-splitting/transcript

https://app.egghead.io/api/v1/lessons/tools-hashing-with-webpack-for-long-term-caching/subtitles

[00:00] When the browser first downloads your application, it puts all of your assets like your JavaScript, CSS, images in a cache. That way, the browser does not have to continuously ask your server for these assets every single time the application is reloaded.

[00:12] The server can be configured to tell the browser how long to keep these assets around, or whether to cache them at all.

[00:18] Depending on your application, it may actually be better to configure your server to tell the browser to keep these cached assets around indefinitely. Then when it comes time to update your application, you simply update your script tag to point to an entirely different URL. Then, the browser has to download that new asset.

[00:34] Webpack comes with special syntax for properties in this output object to allow you to change the URL for these different assets.

[00:41] So, the browser knows that it has to download those files. Let's go ahead and use that syntax now. In the filename property, we're going to add .chunk hash. What that's going to do is if we run the build, the output has this bundled. -- and then this -- hashstring.js. This will be uniquely generated every time we change our source code.

[01:00] But now, if we run the server and we refresh the browser, we're going to have a problem. That's because our index HTML is still pointing to this bundle.js file. So, we can no longer hard code our script tag as we have in our index HTML down here.

[01:15] This bundle.js is going to have to have the chunk hash right there. However, that's not going to work either because our index HTML is simply being copied from on directory to another when we start our server.

[01:27] So, we need to know what the chunk hash is actually going to be, and generate this index HTML based off of that chunk hash. We can do this simply with the HTML webpack plug-in. Let's go ahead and install that MPM install as a dev dependency HTML webpack plug-in. With that installed, we can double check that's installed here with the HTML webpack plug-in.

[01:47] We can go to our scripts, here, where we have copied files. We're no longer going to be copying the index HTML to the disk directory. We'll leave that up to this new plug-in we've installed.

[01:59] Now we'll go to our webpack config. We'll require that plug-in. Now we can simply add a plug-ins array here, with a new HTML webpack plug-in where the template is index.html. If we open up our file tree viewer here, we can see that the index HTML is inside of this source directory. Our context here is that source directory. That's why the template can be relative to that source directory.

[02:23] There's one last thing that we have to do. Because the index HTML is now going to be automatically generated and it's going to have our bundle added to it as a script tag, we can go to our index HTML and remove the script tag line there. The HTML webpack plug-in is going to automatically add that to our index HTML for us.

[02:41] Let's go ahead and save this. We can run MPM start, refresh our browser. Now we'll see in our elements, we have a script with our bundle with that hash that we need to be able to deploy this application with the right script. This will be updated every single time we change our source code. That's how you leverage long term caching with webpack.

[02:58] It's notable that if you were to combine this with the commons chunk plug-in, you'd have to do a couple extra steps, but that's something for another lesson.

[03:05] Let's go ahead and review everything that we did for this. First, we installed the HTML webpack plug-in. Then we updated our copy files script, because we no longer need to do that manually. That's going to be handled by the HTML webpack plug-in.

[03:17] Then, we went to our webpack config. We required the HTML webpack plug-in. In our plug-ins array, we added a new one specifying our template as the index HTML being relative to our context. Then we updated the index HTML to remove the script, because the HTML webpack plug-in is automatically going to add that for us.

[03:34] It's also notable that the HTML webpack plug-in takes a lot more options. So, I recommend that you take a look at the documentation to see what would apply for your specific use case. That's how you can leverage the browser's long term caching with Webpack.

https://app.egghead.io/api/v1/lessons/tools-hashing-with-webpack-for-long-term-caching/transcript

https://app.egghead.io/api/v1/lessons/tools-grouping-vendor-files-with-the-webpack-commonschunkplugin/subtitles

[00:00] Here's our running application. Let's take a look at the size of the bundle. If we refresh, we'll see that we're getting the bundle JS file and it's a whopping 1.1 megabytes for this small application. Most of this is because of jQuery and lodash which we've added to the project.

[00:15] Because we won't be changing these dependencies very often, we can maximize our use of the browser cache by splitting these dependencies out into their own chunk and loading them separate from our application code which does change frequently. To do this, we're going to utilize a plugin built into webpack called Commons Chunk Plugin.

[00:33] First we need to have an entirely separate entry for the vendor files that we want in this extra bundle. We're going to update our entry to have an app which is the original app that we have and then a vendor which is an array of the vendor modules that we want to have in this bundle. In our case, that will be a lodash and jQuery.

[00:52] If we go ahead and run the build, we'll see that we get an error, and that's because we now have two entry files that are being output to the exact same file. We can see that here.

[01:02] We are going to use webpack's interpolation shorthand to make these unique. We'll reference the name of the entry by entering bundle.name. It's notable that you can use the same shorthand in other properties of the output object, but we'll just go ahead and use the file name.

[01:19] If we run the build, we'll see that it generates two files for us, one, that's bundled to app.js and another that's bundled at vendor.js following the name of our entry that we've given it.

[01:31] If we try to run the server, we're going to see that our application has a little bit of a hard time loading our bundle, and that's because now the bundle for our application is called bundle.app.js. Let's go ahead and update the index HTML so that it uses the bundle.app.js. Let's go down here, bundle.app.

[01:52] We'll restart our server and now our application is working. You'll see that the bundle.app.js is still 1.1 megabytes. We haven't totally finished to splitting out our vendor code from our application code. The Commons Chunk Plugin is built into webpack so we can require webpack here, and then we'll add a new property to our configuration called plugins where we'll reference a new webpack optimize Commons Chunk Plugin.

[02:22] This will accept an object, and we can provide several options to the plugin. For our scenario, we can simply provide the name of the entry that we want for the track, so we'll specify vendors here. We'll save that, restart our server and if we refresh, we're now going to have a problem.

[02:36] We get this webpack JSONP is not defined and that's because lodash and jQuery are in a separate file entirely. You'll notice that the bundle.app.js file is much smaller now, and we need to add the bundle.vendor.js file to our index HTML so that we can get lodash and jQuery for our application to work.

[02:57] Let's go ahead and do that now. We'll open our index HTML, scroll down here and add our bundle.vendor.js file. We can restart the server and refresh our browser and the application's working. We have the bundle.vendor.js and the bundle.app.js files, the vendor file being really big and the app file being quite small.

[03:21] The vendor file will be cached long term and the app file will be updated anytime that we update our code. I wish I could say we were done, but we're not. If we run the npm t for npm test or npm run test, we'll see that we setting the node environment to test and then running comma start. Comma's going to have a bit of a hard time here, and that's because it's this exact same error webpack JSONP is not defined.

[03:43] For our test, we don't really care that the Commons Chunk Plugin is used so we're going to conditionally use this plugin by determining whether we're in a test environment. As you saw earlier, we're specifying that the node environment is test when we're running our test. Just like we're doing with this is prod variable, we could just as easily create a test variable and check whether the node environment is equal to test.

[04:06] We'll just have a ternary operator here is test and if we are in test mode, then we'll just say this is undefined. Otherwise, we'll add that new webpack optimized Commons Chunk Plugin. Unfortunately, undefined is not a valid plugin, and so we're going to filter out any undefined plugins with the filter method where we'll take the plugin and we'll coerce that to a bouillon value.

[04:32] If we run the test, we're going to see that everything is going to work just fine because in a test environment, we don't have the Commons Chunk Plugin. In review, to check vendor files, you first add an entry for the modules you want to have chunks together. This is our vendor entry that we have here. We had to change our entry to be an object rather than just this value as a string here so that we could have an app entry for our application and a vendor entry for the vendor files.

[04:59] Because of this, we had to also update the file name so that each one of these entries could have a unique file associated with them, and we used webpack's interpolation shorthand to make these unique based on their name. We updated our index HTML to reference these files properly and we added the Commons Chunk Plugin referencing our vendor entry by name.

[05:20] Finally, to prevent this plugin from being used in a test environment, we added this ternary operator and this filter on our plugins array. That's how you check your vendor files separate from your application code to take full advantage of the browser cache for the vendor files that change infrequently.

https://app.egghead.io/api/v1/lessons/tools-grouping-vendor-files-with-the-webpack-commonschunkplugin/transcript

https://app.egghead.io/api/v1/lessons/tools-chunking-common-modules-from-multiple-apps-with-the-webpack-commonschunkplugin/subtitles

[00:00] Here you'll see we have two applications being bundled by WebPack. The first is our todo app. The second is this AnimalFAX app. These two applications both use the helpers module. This is the animalfaxout.js file that uses a couple of the methods from the helpers module and this is the todo MVC app that also uses a couple methods from the helpers module.

[00:21] Consequently, each bundle uses all of the code for the helpers module, and instead we'd like to split this helpers module into its own file so the browser only has to load and cache the code once for our entire application, rather than once for each page of our application.

[00:36] For a small app like this that only shares a single module this isn't really a huge win, but as the applications grows this can make a real improvement in the performance of our application at load time.

[00:46] To do this we're going to use the CommonsChunk plugin that comes with WebPack. Let's go ahead and jump into our WebPack config, and we'll require WebPack here. Now we can scroll down here, and right after module add plugins as an array, and we'll add a new webpack.ultimize.commonschunkplugin.

[01:08] This will take an object where we can specify a couple of properties. We'll specify the name as common and the filename as bundle.common.js. This is literally all we have to do to make WebPack chunk our common modules together in a single file.

[01:24] Now if we run the build, we'll see that WebPack manages everything for us, and we get a nice bundle.common.js file here, and that holds our helpers module. Then we have our other entries that we've specified in our WebPack config as well.

[01:37] Unfortunately, we're not totally done. If we restart our server, then we're going to see that our applications are totally broken. The problem is that we get error, "webpackJsonp is not defined" in our console.

[01:51] We still need to add this file as a script to the index HTML of both of the pages that reference it. So, we'll go ahead and do that here, and here.

[02:06] Now if we restart our server, we'll see that both applications are now running just fine, and they're loading the same common file that we can see in our network tab, this bundle.com.js. We're taking full advantage of the browser cache for these common modules.

[02:23] I wish I could say we're done, but there's still one more thing left to do. If we run our test, we're going to get that same error that we had before with the webpackJsonp is not defined. For the test we don't really care that the CommonsChunk plugin is used, so we're going to conditionally use this plugin by determining whether we're in a test environment.

[02:40] If we open up our WebPack config, we'll see that it's a function that accepts an environment object that has properties on it that we can use to know what our environment currently is, and if we open up our common config where we get the WebPack configuration its passing test is true. So, we can simply conditionally load this plugin based off of ENV.test.

[03:02] We can say ENV.test. If we're in test, then this will be undefined, otherwise we'll specify a new WebPack plugin, and because undefined plugins are not valid we'll have to call filter the plugins that are actually defined.

[03:20] Now if we run our test again, we'll see that they pass just as they did before. It's notable that if you wish to combine this with an explicit vendor trunk strategy, you can add another CommonsChunk plugin to this plugins array with the configuration for the vendor chunk.

[03:35] You'll likely be required to explicitly list the entries to use in the CommonsChunk, though. You can do this by adding a chunks property with an array of the entry names to have this plugin apply to.

[03:48] In review, to chunk common files together you simply add the CommonsChunk plugin and specific a name and a filename for the chunk. Then update your index HTML files for each of your apps to utilize the new file.

[04:00] Finally, you have to exclude the plugin in a test environment. That's how you chunk your common modules into a single bundled file to take full advantage of the browser cache for those modules.

https://app.egghead.io/api/v1/lessons/tools-chunking-common-modules-from-multiple-apps-with-the-webpack-commonschunkplugin/transcript

https://app.egghead.io/api/v1/lessons/tools-optimize-react-size-and-performance-with-webpack-production-plugins/subtitles

[00:00] Webpack comes pre-built with a bunch of optimization plugins that you can utilize by specifying this -p shortcut to the Webpack 2 CLI. If we run the production build as is with the Cameron build prod, it's going to go ahead and build our application using all of the production, optimizations here. We'll see a whole bunch of output.

[00:23] I've added [inaudible] application to give us a bit of a better sense of what things will look like in a real application. We see a lot of condition always false or true, removing that code, unreachable code. Webpack is doing this using the Uglify JS plug-in. Here, we see that the final bundle size is 164 kilobytes, and we have a source map here as well.

[00:48] Just for comparison, if we run the regular build, we're going to see the file size is much bigger. The minified version is 164 kilobytes. The unminified version is 832 kilobytes. For most applications, you'll probably be fine just going with the -p on the CLI.

[01:06] If you want to be able to fine tune some of the plugins that Webpack is using, or get rid of all that Uglify output, because it makes it really difficult to debug problems. Then you're going to want to specify these plugins yourself. That's what we're going to do in this lesson.

[01:21] The first thing that we're going to want to do is make sure that we remove this -p. If we don't do that and start adding these plugins to our Webpack configuration, we're going to wind up with double minification, which generally leads to bad bugs in production that are really hard to track down.

[01:34] We'll make sure we remove it from here in our scripts. Then we'll go ahead and add the plugins in our Webpack configuration. These plugins are available from Webpacks, so I'll require that here. I've added a couple of utility functions here. I'm going to leave their implementation as an exercise for the viewer.

[01:52] Here we're going to add a plugins array. We'll use that remove empty, so that we don't wind up with any undefined values. The first plugin that we're going to add is the New Webpack.optimize DedupePlugin. This one, we don't actually have to do anything with.

[02:10] The DedupePlugin essentially looks at all of your modules and determines if any of them are the same. If they are, it will deduplicate those, so you only have one copy of that module in your bundle. This can happen if you're using NPM version 2 to install your dependencies.

[02:25] If you have two dependencies that have one common dependency between each other, then you'll wind up with some duplicate code. This plug-in will alleviate that program. Next, we're going to say, "If production." If production only plug-in.

[02:38] This will be "New Webpack.loader options plugin." This one is actually included by default with that -p argument, but it only specifies minimize is true. It will also specify debug is false just to speed up our build times.

[02:56] The loader options plug-in essentially tells all of our loaders that we're in minimized mode, and they can optimize according to whatever optimizations they can do, or the code that they're loading. I should also note that the loader options plug-in is only available in Webpack 2.

[03:11] Most of the plugins and the API to Webpack are the same between Webpack 1 and 2, but this is one in particular that's only available in Webpack 2. Next, we're going to add another plug-in that saves us a lot of trouble. That is in production mode also. New Webpack, define plugin process.env.node_nv is production as a string.

[03:36] What this is doing is it's taking any instance of process.env.node_env and replacing it with a string production. That way when React or even in our own code, we say process.env.node_env is production. It's going to replace this with production.

[03:55] It's going to evaluate this as true. In any instance where that value actually ends up being false in an if statement, for example, it can go ahead and remove that code as dead code. That's generally done by the UglifyJS plug-in which we'll add next.

[04:10] This saves us a ton of space when using React in particular, but it can also save us some space with other libraries as well. I should note also that this isn't just a size optimization, but it's also a performance optimization in the case of React. For example, it will disable runtime checks for your prop types.

[04:27] Our last one is also if prod. We're going to have a new Webpack, optimize UglifyJS plug-in. We're going to specify compress options. The first one is screw_ie8, true. This is a legitimate UglifyJS option. Then we'll also specify warnings is false.

[04:50] This will make it that our console is not totally loaded with warnings when we're Uglifying and building for production. With those plugins going, we can run npm run build prod. This will do basically the same thing that it did when we had the -p on the CLI, except, we've been able to fine tune it a little bit, so Uglify doesn't spit out a ton of output.

[05:13] We've added a couple other plugins as well. These are a couple of plugins you can use to really shrink your build. I should also note that if you're really concerned about size, you should consider using the common strength plug-in. That's a lesson for another day.

[05:26] In review, all that we had to do here is in our pegasus JSON. We changed our build prod to remove the -p. Then we went into our Webpack config, we required Webpack, added a couple of utility functions for ourselves, added this plugin's array, and added a couple of these plugins for a production build.

https://app.egghead.io/api/v1/lessons/tools-optimize-react-size-and-performance-with-webpack-production-plugins/transcript

https://app.egghead.io/api/v1/lessons/tools-expose-modules-to-dependencies-with-webpack/subtitles

[00:00] Here we have a module that depends on Lodash to add a couple mix ins to be used later in the application. We're loading this module in our app.js file, and if we go ahead and run npmstart to start up our server, we're going to get an error. We're going to see "Underscore is not defined," and that's because this module's not requiring Lodash.

[00:19] Now that would be really easy to fix if we had control over this module. If it's not a dependency, or something, we can just say, "Import Lodash from Lodash," then we save that, and everything works just fine.

[00:33] But, let's assume for a moment that this suite Lodash mix ins module is not ours, and it's one of our dependencies. How can we expose Lodash to this module without just sticking it on the window?

[00:44] We can do this a imports loader. Let's go ahead and install that as a dev dependency, and then in our app.js file, we're going to use web packs enhanced import to expose the Lodash module to the suite Lodash mix ins module.

[01:00] We'll specify the imports loader, and here we'll just add an ES link, disable lines, so we don't get that red underline there, and then we'll add a query string where this underscore variable will be assigned to the Lodash module.

[01:15] We'll save that, we'll run npmstart again, and if we refresh our browser everything seems to work just fine.

[01:20] Let's go ahead and open up, in the sources, those suite Lodash mix ins, to see what actually happened. Here we have this comment, "Import from imports loader," and it adds this, "require for the Lodash module," then it's within scope, so we could call this whatever we want, whatever, whenever, and if we refresh we're going to see it's going to be called whatever.

[01:47] That's the syntax for this loader, for the query string, and we're off to the races, we're great. However, I don't like having this special syntax inside of my import statements, so we're going to take this, and move it to our web pack config. Let's go ahead and do that now.

[02:03] We'll just cut this right here, and we'll go to our web pack config, and we're simply going to add another loader, where the test will be simply require.resolve, so we'll resolve this module, and we're just going to resolve directly to the specific module we want this loader to apply to, so source, JS, non node modules, suite Lodash mix ins, and then we'll specify our loader is exactly what we had before.

[02:29] Then if we save that, and we'll restart web pack dev server, we go back to our application, and refresh, and everything is working just fine.

[02:38] In review, all that you need to do to expose a variable to another module that you don't have any control over is by simply installing the imports loader, and then the web pack config.

[02:50] We specify a new loader in this array of loaders, where the test is simply using require resolve to reference the specific module that we're trying to apply this loader to, and then we specify the loader as the imports loader, with the query string of the variable, and the module that we're going to be exporting from.

[03:09] This query string is pretty powerful, and you can check that out to assigned window, to this, and all kinds of different things, to expose different things to modules that you have no control over, and that's how you use the imports loader.

https://app.egghead.io/api/v1/lessons/tools-expose-modules-to-dependencies-with-webpack/transcript

https://app.egghead.io/api/v1/lessons/tools-import-a-non-es6-module-with-webpack/subtitles

[00:00] Here, we have a module called leftpad that exposes itself on the window. We're using it by importing it and expecting it to export itself, so that we can use it like a regular ES6 module.

[00:10] If we go ahead and run our application, we're going to get an error when we run that code. If we open up our console here, we're going to see pipe error. That's because leftpad is not defined because it's not actually exporting anything.

[00:23] This would be pretty easy to fix if we can simply say module.exports = leftpad. We can refresh here and say sweet. Let's assume for a moment that we don't have control over this module.

[00:35] How can we force this module to expose the things that we need it to expose, so that we can use it like a regular ES6 module? We can do this with the exports loader.

[00:43] Let's go ahead and fix this code back up to where it was before. We'll npm install as a dev dependency the exports loader. We can verify that we have that installed here in our package.json. We'll go back to this module import. We'll use Webpack's enhanced import statement, so that we can test things out.

[01:03] We'll say exports, and that will reference the exports loader. We'll add the exclamation point there to indicate that this is indeed a loader. We'll add a query string here with leftpad. That will tell us to export the leftpad variable that's in our module.

[01:20] We'll go ahead and add an eslint statement line there, so that we don't have that red line there. There's actually an eslint plugin that you can use that can understand Webpack module imports. I recommend you go look that up.

[01:34] If we run npm start to start up our server again, then we refresh our browser, we can say sweet, and everything is working fine. We're using the exports loader to ensure that what is being exported is what we expect.

[01:49] If we look at the leftpad file, we're actually seeing at the bottom here, a module exports is added. This is being added from the exports loader.

[01:57] This still isn't solving the problem of polluting the global namespace on window. We're still getting window.leftpad there. We can see that still here. We're going to actually also use the imports loader, so that we can make sure that this module doesn't pollute the global namespace.

[02:14] To do this, we'll npm install as a dev dependency the imports loader. In our enhanced import here, we'll also add imports as another loader. The query will be window is assigned to an empty object.

[02:31] If we run npm start and refresh our browser, we'll see that now, at the very top of the file, window is being assigned to an empty object. If we open up our console here, we can say window.leftpad, and we get undefined.

[02:45] We're not polluting the global namespace. We're exporting this module as a regular ES module, so that we can use it throughout the rest of our code base like a regular module.

[02:54] There's one last thing that we're going to do here. That is we don't have to do this crazy import statement everywhere we're using this module. We're going to actually extract this into our Webpack config.

[03:06] We'll go to our Webpack config and add another loader. The test will be directly to this specific module. We'll add a loader here. We'll simply paste in what we had before. We'll remove that last exclamation point. This is going to work fine.

[03:21] I don't like the way that this looks with multiple loaders. Each one has a query. We're going to use the loaders property instead, which accepts an array of loaders. Instead of being separated by an exclamation point, they're two separate elements.

[03:37] If we restart our server, we can refresh the browser, and we'll see things still work. We can open up our leftpad. We still see the imports from the imports loader. We see the exports from the exports loader.

[03:53] In review, to fix up a module that we don't actually have access to, all that we needed to do was add the exports loader dependency. Then, we added that to our loaders for this specific module.

[04:05] To prevent it from clobbering the global window object, we also added the imports loader as our dependency, and added that as one of the loaders for this specific module as well. That's how you force a JavaScript file to export its contents as a regular module.

https://app.egghead.io/api/v1/lessons/tools-import-a-non-es6-module-with-webpack/transcript

https://app.egghead.io/api/v1/lessons/javascript-initialize-a-webpack-project-with-karma-for-testing/subtitles

[00:00] To set up our project to use Karma for testing, we're going to need to do a few things. We'll start out by installing a couple dependencies. We'll NPM install as dev dependencies, Karma, karma-chrome-launcher to launch Chrome to run our tests, and then Mocha for our testing framework, and then karma-mocha to make testing with Mocha and Karma a little easier.

[00:24] We'll go ahead and install these dependencies. With these dependencies installed, we can verify that here in our package.json. We have those there. We're now going to initialize Karma. To do this, we're going to run in the node_modules directory in the bin, Karma.

[00:40] As we just installed Karma, the Karma binary is now available in our node_modules directory, and we'll run the init script. Here, we're going to be using the Mocha framework. We will not be using RequireJS. We will be using Chrome.

[00:54] It needs to know where we're going to be putting our test files. I'll go ahead and create a test file right now, controller.test.js, right next to the controller.js file. Our test files will be in source/js/***.test.js.

[01:10] We'll use that glob so that it goes through the entire JS folder recursively. We don't need to exclude any patterns. That will capture only the patterns we want to include. We'll go ahead and ask Karma to not watch all the files, and run tests on change. We'll do that ourselves elsewhere.

[01:30] We can look at our Karma config file that was generated for us. I'm going to go ahead and clean this up a little bit. With that cleaned up, let me go ahead and explain a little bit what's going on here. We have a function that is being exported from this module.

[01:44] I just call it set Karma config. It accepts a config, and it sets this object on this config. This object has a base path. That just means that the files, exclude, and preprocessors, those values will be relative to that base path. We just left it at the default of an empty string.

[02:01] The framework we chose is Mocha, and so it's going to use the karma-mocha plugin to load Mocha for our testing framework. The files that we want to load into the browser are files that match this glob. We don't need to exclude anything. I'll just remove that.

[02:16] We will need preprocessors eventually, but we'll add that a little bit later. I'll remove that. Our reporters, we're just going to use the default progress reporter. The port is the default. We'll leave the colors the same, and the log level.

[02:30] Auto-watch is false, and we'll add a watch mode a little bit later. The browsers is Chrome. We could add Firefox, and Internet Explorer, and different browsers here, but we'll just stick with Chrome. Single-run, we're actually going to set to true here.

[02:45] We'll set up a watch mode here in a little bit. Concurrency is infinity. That's the default there. Let's go ahead and add a little test here. I'll just go ahead and paste that in. With that, we're going to want to add a test script to our package.json script so that we can run the test when we like.

[03:04] We'll add test here, and it will simply be Karma start. We'll default to using this Karma cont file, so it will load our options that we specified in there. If we run NPM t, which is short for NPM test, it goes ahead and runs all of our tests.

[03:20] It executed the one test that we have successfully, and we're good to go. Let's go ahead and just add a watch mode as well, watch test. This is great for doing test-driven development. You run the test every single time you make a change to the code base.

[03:38] Here, we'll run NPM test, the exact same as this script, but we're going to pass along a couple arguments, auto-watch, and no single-run. With that, we can run NPM run watch test. We can start developing.

[03:58] It's run one test. If we add another here, it runs our test again. We have two successful tests. If we go ahead and throw a new error, failure, then we're going to get that one of our tests failed. We're good to go with our watch mode.

[04:17] Let's go ahead and review really quickly what we had to do to set this up. First, we installed a couple dependencies, Karma, karma-chrome-launcher, and karma-mocha, and then the Mocha testing framework.

[04:29] We ran Karma init. In the node_modules bin, we have this Karma binary right here. We utilized that in our command line to run the init script. Karma generated this for us. We made a few slight modifications, simply changing single-run, as well as removing a couple unneeded properties.

[04:51] We created our controller test file, where we added a couple of tests. We added our test and watch test scripts so that we could run these regularly as we're developing our code. One last thing that we're going to do while we're here is we have this validate script that runs as part of our pre-commit hooks.

[05:09] We're going to go ahead and add the test script to the things that are run every single time we commit, that way we don't push any commits that are going to break our test. That's how you initialize your project Karma config.

https://app.egghead.io/api/v1/lessons/javascript-initialize-a-webpack-project-with-karma-for-testing/transcript

https://app.egghead.io/api/v1/lessons/javascript-use-chai-assertions-for-tests-in-a-karma-project/subtitles

[00:00] For our test, we want to actually have an assertion in here. We're going to replace this with "expecttrue.to.be.true." This is using the Chai Expect Assertion Library.

[00:11] If we go ahead and run our test right now, we're going to get an error. That's because "expect" is not defined. We need to install the Chai Assertion Library and the Karma Helper so we can get the expect assertions. We'll do that with "npm iD chai" and "karma-chai."

[00:28] We install those dependencies as devDependencies. With those installed, we can check our package.json to ensure Chai and Karma-Chai were installed.

[00:37] We simply need to go to our Karma config and, in our frameworks, add "Chai" so that Karma will load the Chai Helper. We can use the expect assertions.

[00:49] Now, if we run our test, we're going to get "Success," here. Let's go ahead and add another one. We'll run our test again. Those were executed successfully.

[00:59] In review, for us to get our Chai assertions, we can simply install Chai and Karma-Chai. In our Karma config, in the frameworks, we add Chai as one of the frameworks we're using for our test. That's how you add Chai to your Karma configuration.

https://app.egghead.io/api/v1/lessons/javascript-use-chai-assertions-for-tests-in-a-karma-project/transcript

https://app.egghead.io/api/v1/lessons/tools-use-karma-for-unit-testing-with-webpack/subtitles

[00:00] We want to be able to actually import our controller and start unit testing it. If I were to try that import controller from controller, and go ahead and run the test, we're going to get this Uncaught SyntaxError Unexpected token import.

[00:16] That's because the browser doesn't understand the import statement. Even if we were to write this using require statements instead, the browser still wouldn't be able to understand that because it has no way of resolving those required statements. That's where Webpack comes into play.

[00:32] What we need to do is tell Karma to pre-process all of our test files with Webpack, so that these import statements are resolved, and the bundle for that test file is delivered to the browser to rerun for our test.

[00:45] To do this, we're simply going to install as a dev dependency the karma-Webpack plugin. With that, we'll go our package.json just to verify quickly that we have the karma-Webpack plugin installed here. Then, we can go to our Karma config. Here, we're going to utilize this Webpack plugin for Karma. It'll bundle each of our test.

[01:06] For Karma, Webpack is what's called a pre-processor. We basically want to pipe all of our test files through Webpack, so Webpack can bundle these and prepare them for delivery to the browser. Then, the browser will take this bundle and run it, which will run our test.

[01:21] We're going to start out by adding a pre-processor's object here. In here, the key is going to be the glob that we want to have pre-processed. In our case, we want all of these files to be pre-processed.

[01:34] I'm going to extract into a variable called file glob. We'll put that up here. We'll add that as our key. The value will be an array of the pre-processors we want to have these files run through, which will be Webpack in our case.

[01:50] If we run our test, we're going to see that it still is not working. We're still getting the unexpected token import. That's because Webpack needs to know what configuration it needs to use to bundle our files.

[02:02] The way that we tell Webpack what configuration to use is by using a Webpack property. Here, it will take an object with our configuration. We don't want to duplicate our configuration both in our Karma config and our Webpack config.

[02:15] We can actually require this, because it's a regular node module. It exports a function that accepts an ENV object. If we simply require this and then invoke that function, it will return us the Webpack configuration that we're using for our app, which incidentally will work fine for Karma.

[02:34] Let's go ahead and do that here. We'll have a Webpack config that is equal to require of the Webpack config file. We'll invoke that with a Webpack ENV, which will simply be an object with test as true.

[02:51] We're not actually using test as an ENV property in our Webpack config file right now. It's totally a reasonable thing that we could do in the future. For good measure, we'll do that now.

[03:02] We'll take this Webpack configuration. We'll assign to the Webpack property. If we go ahead and run npm t, we'll see that this actually now runs. We'll see a little bit of output from Webpack here and eslint. Our tests are running now.

[03:18] Let's go ahead and update our test to actually utilize the controller constructor that we're importing. We'll simply expect that the controller constructor exists for now.

[03:27] With that, if we run npm t to run our test, we're going to see this output from Webpack. That can get annoying, especially when you're in watch mode. We're going to disable that in our Karma config.

[03:41] We go into our current config here. We can add Webpack [inaudible] . This will simply be an object that has a no info property as true.

[03:52] If we run our test again, we see that we don't get that output from Webpack. The output that we do see is relevant to what we're interested in seeing.

[04:01] Let's go ahead and review. The first thing that we had to do is install the Karma Webpack plugin so that we can use that as a pre-processor for our test. Then, we went into our Karma configuration. We added a pre-processor using the same file glob that we use for our files. We defined the pre-processor to be Webpack for those files.

[04:23] We got our Webpack configuration from our Webpack config file, where we passed in a Webpack ENV to that function to get our Webpack config. We assigned that to the Webpack property in our configuration. We went ahead and updated our controller test to utilize the controller import.

[04:41] Finally, to save ourselves from a little bit of noise in the output, we added a Webpack middleware here with a no info property set to true. That's how you add Webpack pre-processing to your Karma configuration.

https://app.egghead.io/api/v1/lessons/tools-use-karma-for-unit-testing-with-webpack/transcript

https://app.egghead.io/api/v1/lessons/tools-add-code-coverage-to-tests-in-a-webpack-project/subtitles

[00:00] To add testing code coverage to our webpack application with Karma, we can install as a dev dependency the karma-coverage plugin. With that installed, we can verify that installed right here.

[00:13] Then, with our Karma configuration, we can add the configuration for this plugin. We'll add it to our reporters as the coverage reporter. Then, we'll add a coverage reporter object here, where we configure this plugin. It accepts a reporters array here. These are the different types of reporters that we want to have for our output.

[00:37] I'll go ahead and add a couple here. Here, we have LCOV report, and JSON report, and a text summary report. The LCOV report will generate a HTML report that we can look at in the browser locally. Then, the text summary is nice because it adds the output in our terminal, so we can look at the output there as well as a summary.

[00:57] We're going to be saving this to the coverage directory. With that, if we go ahead and run our test, we're going to get the text summary report right here in our output. We're also going to get this coverage folder with the LCOV report right here. It has an index.html that we can open up and look at the coverage report.

[01:18] If we simply open the coverage/lcov-report/index.html, then we're going to see that we have 100 percent coverage. Hurray! Just kidding. We have 100 percent of nothing. We need to actually instrument our code for coverage, so that Karma knows what to report.

[01:35] Because our code is being transpiled by Babel, we need to instrument our code for coverage before Babel transpiles it. Otherwise, we're going to be instrumenting transpiled code for coverage, and we'll get incorrect coverage numbers.

[01:49] There's actually a coverage plugin for Babel that we can utilize to instrument our code for coverage before everything else is transpiled. We'll install it with npm install as a dev dependency, babel-plugin__coverage__. With this installed, we can verify this in our package.json right here. We can now add this plugin to our Babel configuration in our .babelrc file.

[02:15] In our scenario, we only want this coverage plugin to be added in a test environment. We don't want to actually ship instrumented code to production. That would be a bad idea.

[02:24] We're going to utilize the ENV property in a .babelrc file. Add ENV object here. In here, our ENV will be test that we're applying these plugins to. The plugin that we're going to be using is the coverage plugin here.

[02:43] Now, to have this plugin be applied in our scenario, we need to set the Babel environment, or the node environment, to test when we start up Karma. We can do this easily in our Karma configuration by saying process.env.Babel_Env = test.

[03:00] Now, if we run our test, we're going to see some coverage. If we look at our coverage in the browser, we'll see we have a JS file, we have our controller. We're not getting very good coverage on this because we're not doing much with that file right now as far as test.

[03:17] We also see the controller.test.js file. We have great coverage on this. It's loading our coverage numbers because we don't care about the coverage of our test. We mostly care about the coverage of our application code.

[03:29] This needs to be excluded from what is being instrumented by the coverage plugin. We can do this fairly easily in the .babelrc file by providing options to this coverage plugin.

[03:39] We do this by turning this plugin into an array. The second item in the array are the options. Here, our option will be Ignore. Here, we'll provide a glob to ignore. That will be *.test.*. Anything that has .test in the name, we don't want to have instrumented for coverage.

[04:00] Now, if we run the test again, we'll see that our coverage numbers are a little bit different. If we refresh our browser, we'll see that only the controller is being reported as having any coverage recorded.

[04:12] Even though this coverage isn't very good, this is what we want, so that we can cover only our application code. Then, we can start running test for the controller and see this coverage number go up.

[04:21] I've taken the liberty of running actual test for this controller, something that will allow us to create a new instance of the controller. I created a Views tab and Models tab file. I don't want to instrument those for coverage either. I added this to our Ignore, so that we ignore both the test and stub files.

[04:40] Now, we can actually see some more of our code being covered if we run npm t to run this test. We'll see that the text summary for our coverage indicates that our coverage has gone up. If we refresh our browser, we'll see that the controller has some more coverage.

[04:56] We can start iterating on this. We could also run this with the watch mode npm run watch test. This way, we can iterate, and add more tests, and see our coverage go up, and review the coverage report in the browser to find the different places in our code that are not being covered.

[05:14] Let's go ahead and review. What we had to do to get coverage working in our Karma webpack project, we first had to install the karma-coverage reporter. Then, we went in to our Karma config file. We added coverage to the list of reporters.

[05:28] We added a coverage reporter. Then, we added some configuration for the reporters that we wanted to utilize. Then, we installed the coverage plugin for Babel, and added that to our .babelrc file, but only for the test environment.

[05:42] Then, we went to our Karma config and added Babel_ENV = test, so that this plugin would be utilized. Then, we discovered that the controller test file was being included. We added this Ignore option to our coverage plugin. Then, I added a couple extra test-related files and actual test. We added this stub to our ignore glob.

[06:08] One last thing that I'm going to go ahead and add to this is, in our validate script, which is run as a pre-commit hook and is useful when starting up the project, I'm also going to have it run the test.

[06:20] Now, when I go ahead and commit code, it also runs the test to make sure that none of the test break. That's how you add code coverage to your Babel transpiled code with Karma.

https://app.egghead.io/api/v1/lessons/tools-add-code-coverage-to-tests-in-a-webpack-project/transcript

https://app.egghead.io/api/v1/lessons/tools-ensure-all-source-files-are-included-in-test-coverage-reports-with-webpack/subtitles

[00:00] If we look at our code coverage numbers right now, it's actually a little bit misleading. Right now we're looking at about 25 percent of our statements in our project being covered, but that's not entirely the case.

[00:11] If we look at the report in the browser, we see that only controller.js is being covered. But in the project we have a bunch of files that should have code coverage reported on them. In this lesson, we're going to make sure that those files are also instrumented for coverage.

[00:27] To do this, we need to load all of the files that we want instrumented into the browser so that they're instrumented for coverage and Karma gets that report.

[00:36] Right now we have this fileglob that's matching all of our test files. Only the test files are loaded and then Webpack resolves the requires and so we get the source files from that. But we're going to have all of those source files loaded into the browser.

[00:51] Here we're going to actually change fileglob to be testglob, because that's truly what it is. We'll copy that and create a new glob called sourceglob. This one we'll modify slightly to have anything that does not include test or stub.

[01:11] We'll add the sourceglob to our list of files and then we'll add another item in our pre-processors here for sourceglob. We're still going to be pre-processing those with Webpack.

[01:25] If we run our tests, you see before we had 26 percent on our statements. After these changes we only have 23 percent on our statements. If we refresh our coverage report, we'll see that we have all the files in here that we want instrumented for coverage, not just the ones that have unit tests for them already.

[01:44] This gives us a much better idea of what the coverage for our entire project is and it gives us something to work toward. The one last thing that we're going to do if we're going to be working toward a higher number in our code coverage is we don't ever want our code coverage in our project to go down.

[02:01] We're going to add a check to make sure that our code coverage never goes down. To do this, we're going to install as a dev dependency Istanbul. The coverage report that we're generating with Karma is compatible with Istanbul and Istanbul has a CLI that will allow us to check that the coverage meets a certain threshold.

[02:21] If we go to our scripts here, we'll add a check coverage script and this is where we're going to use the Istanbul CLI. We'll use the check coverage command. Here we're going to add a threshold for the four aspects of our coverage. If we scroll up here, we have our statements, branches, functions, and lines.

[02:42] For our statements, we want 23 percent. We don't want to drop below that number. For branches, it's going to be five percent. For functions it'll be 9 percent, and for lines it'll be 24 percent.

[02:57] If we run MPM, run check coverage, we'll see this output and the script passes. There's no error I'll put at all, but if we were to bump one of these up to above our threshold of coverage currently, then we're going to get an error indicating that our coverage is below the threshold.

[03:17] We can go ahead and add this check coverage to our validate script, so when people go to commit the pre-commit hook will run and they won't be able to commit anything that drops the coverage below the threshold. This will help us work toward a higher coverage percentage in our code base.

[03:33] However, we can't run this in parallel with the test. This check coverage script has to run after the tests have run and the coverage report has been collected. But with MPM run all, we can add this serial flag here and we'll put check coverage right there.

[03:49] If we run our validate script, we'll see that it runs validate Webpack in parallel, our linting, our testing, and then it runs our check coverage.

[03:58] We see again that that is failing. Let's go ahead and lower that back down to where our threshold is right now. We'll rerun our validate script and everything will pass.

[04:08] Let's review. To make sure that all of our code is instrumented for coverage so that we can get an accurate reporting on our entire code base, not just the code that's under test, we added this sourceglob that matches all the files that don't match test or stub in the filename.

[04:25] We added that to our files here, and then we also added that to our pre-processors so that it will be pre-processed with Webpack. That was enough to get everything instrumented for coverage.

[04:37] We also added Istanbul as a dependency and added a check coverage script that uses Istanbul's check coverage to make sure that we don't drop below our coverage threshold. As we work toward better coverage in our code base we can increase this threshold so we never drop below the threshold that we set.

[04:56] That's how you enforce coverage in your entire application.

https://app.egghead.io/api/v1/lessons/tools-ensure-all-source-files-are-included-in-test-coverage-reports-with-webpack/transcript

webpack v1 from Kent

Kent C. Dodds

Course Content