Webpack 2 and plugins, making the best better
If you haven’t read my earlier article on Webpack I suggest going back and checking it out, just to get up to speed. Here. Excellent!
When I left off, I had the whole project bundled up, transpiled and ready for use with our app. This is as perfectly fine structure except, what do we do with the style and HTML? It is completely acceptable to make a second set of entries, and exports to create these two components. Maybe we want the HTML page to have different links ex. we wanted to use CDN’s in full length when we’re developing, but want to the minified versions in the production bundle. Additionally, what about our stylesheets, Those are only referenced from the HTML, so their dependencies won’t be mapped by Webpack. Don’t you worry, I gotcha covered.
In the last blog we talked about the modules, and their rules which outline how webpack handles certain page types. In addition to these, webpack has ‘plugins’ which can do a host of other things. The two most important ones for this talk are ExtractTextPlugin and HTMLWebPlugin, to get them just npm install as before.
Above the module takes into account that there may be a stylesheet of some format and to use the style-loader, or css-loader if it is encountered, however as I pointed out, where does the style dependency reside? on the HTML page, so theres a sneaky little thing that has to be done.
Notice the change to the style rules, the same two loaders are used, but now Webpack will extract the style into a separate sheet and build it into our ‘output’ pathway. The second thing to notice is the new ‘plugins’ array. This will be where we load all of our new plugins. The extract Text Plugin lets you declare a few things, but the most important is the resultant file name, styles.css.
The next plugin I said we’d cover is the HtmlWebpack plugin, you know the drill, just npm install that. Since we’re trying to automate our whole process, and minimize the space our app may take up, it would be to our advantage to minify our HTML page, or pages with our new bundle. This way when we switch to production mode, the client code will be optimized for space resulting in greater page-load speed. There area a couple of options here. We can duplicate our index.html page into our output path and have two copies of it, which will work, or just make Webpack do it for you.
On its base level HtmlWebpack builds an HTML page automatically for you, and maps any dependencies from your bundle to it, which is awesome; one less thing to do, but it only maps dependencies mapped by Webpack. So if you want to include CDN’s like bootstrap, or react-router, or what have you, then you’re S.O.L? Fear not, HTMLWebpack can handle this for you.
The HTMLwebpack plugin also has a series of parameters that can be assigned. The ones I would like to point out are to the left. From top to bottom, whats happened is, we’ve minified our html, hashing means that each time files are created a new hashed filename is made, this helps the browser know if the cached copies are no longer applicable when revisiting a site. The filename, Template and inject keys are where the magic happens. The filename, maps where the new file will end up, the template is the file that will be copied to make the exported html. This means that if there are unmapped dependencies necessary to the operation, such as CDN’s or un-bundled pages they will be copied with the new HTML pages. I found this particularly useful, when I started to make multiple Webpack builds, for dev and production environments. I could template two separate HTML’s, one which referenced minified versions of my CDN’s and another which had full sized, so that I could get all the benefits of both. The last line, inject means that any file that comes as a result of the build will have its dependencies injected into the resultant html file.
Those of you with eagle eyes will notice a third plugin which I neglected to mention. Uglifyjsplugin, it’s a method of webpack, so just call and use it as a plugin, and your JS files will be uglified. Pretty self explanatory.
At this point your config file should look similar to this.
Webpack 2 and plugins, making the best better pp, however if changes are made to the files, you will need to rebuild, and reserve your files before any of it will be observable. Fear not, in the next blog, i’ll go over dev-servers, and Hot-loading, both which will be necessary when building single paged apps, so be on the lookout.