#2 Webpack: Transpiling and Bundling

Correction

Depending on how you chose to install the npm packages from the previous article we may need to update the uglifyjs-webpack-plugin package. First you will want to open the package.json file and check the version number of the package. If the version says '1.0.0-beta.3' then everything is fine. If on the other hand it says something different, for example 0.4.6, then we need to update the package. We do this by navigating a console to the root of our project and typing in npm uninstall uglifyjs-webpack-plugin --save and pressing enter to uninstall the package and then typing in npm install uglifyjs-webpack-plugin@1.0.0-beta.3 --save and pressing enter to install the version we need.

Importing

/*********************************
* Environment and imports
*********************************/
const environment = process.env.NODE_ENV || "development";
const autoprefixer = require("autoprefixer");

const webpack = require("webpack");
const BundleAnalyzerPlugin = require("webpack-bundle-analyzer").BundleAnalyzerPlugin;
const ExtractTextPlugin = require("extract-text-webpack-plugin");
const UglifyJsPlugin = require("uglifyjs-webpack-plugin");

Entry

Next we will create a couple of functions and our entry object (b) that will be used to specify the entry points of our application and thus specify the bundles that should be created. As has already been stated before we will use the Source folder to hold all of our front-end files. The sass folder, that we created previously, will contain all the style files that are not related to an Angular component and the app folder, that we also created previously, will likewise contain all of our typescript files not related again to an Angular component. It is important to note that the '.site' suffix of the scss files is important since we will use it to indicate that the file requires the special processing, via the extract text plugin, mentioned above.

/*********************************
* Entry
*********************************/
function siteScripts(name) {
    return `./Source/app/${name}.site.ts`;
}

function siteStyles(name) {
    return `./Source/sass/${name}.site.scss`;
}

function siteScriptsAndStyles(name) {
    return [
        siteScripts(name),
        siteStyles(name)
    ];
}

const entry = {
    "main": siteScriptsAndStyles("main"),
    "vendor": "./Source/app/vendor.ts"
}

console.log("Hello World!");

@import "../../node_modules/normalize.css/normalize.css";

@import "2-base/_base.scss";
@import "2-base/_media-queries.scss";

@import "../_bourbon-neat.scss";

Javascript Output

The following code (f) sets up the output object for our javascript bundles depending on the environment we are currently running. The result of using this object is our javascript files are output to the wwwroot/js folder where the template variable 'name' is extracted from the specified entry point for that particular set of files. And of course if we are running a production build the output will have the '.min' addition to the filename automatically. The path info option adds information, in the form of comments, in the bundles for the webpack modules that are created.

/*********************************
* Javascript Output
*********************************/
const output = {
    filename: "./wwwroot/js/[name].bundle.js",
    pathinfo: true
};

if (environment === "production") {
    output.filename = "./wwwroot/js/[name].bundle.min.js";
    output.pathinfo = false;
}

Plugins

Next we configure the webpack plugins (g) that we will be using. First we will use the commons chunk plugin to create our third party 'vendor' bundle. Once that is added we configure the extract text and the loader options plugin. Again the extract text plugin will output our css bundles with the appropriate name depending on environment and the loader options plugin will run autoprefixer on any css files that we create. In almost all, if not all, the projects I have done I have needed to inject some information from the node environment into the bundle created by webpack. In order to do this we will use the define plugin. For now we are just creating an object with the property 'process.env.NODE_ENV' and settings its value to the string value of the node variable of the same name. You can of course use this method to define whatever properties you like for use within your bundles. Finally if this is a production run we will use the uglify plugin to minify all of our files and the bundle analyzer plugin in order to analyze the size of our bundles.

/*********************************
* Plugins
*********************************/
const plugins = [
    new webpack.optimize.CommonsChunkPlugin({ name: "vendor", minChunks: Infinity }),
    new ExtractTextPlugin({
        filename: environment === "production" ? "./wwwroot/css/[name].bundle.min.css" : "./wwwroot/css/[name].bundle.css",
        disable: false,
        allChunks: false
    }),
    new webpack.LoaderOptionsPlugin({
        options: {
            postcss: [
                autoprefixer()
            ]
        }
    }),
    new webpack.DefinePlugin({
        "process.env": {
            "NODE_ENV": JSON.stringify(process.env.NODE_ENV)
        }
    })
];
if (environment === "production") {
    plugins.push(
        new UglifyJsPlugin({
            uglifyOptions: {
                mangle: {
                    keep_fnames: true
                },
                compress: {
                    warnings: false
                },
                output: {
                    comments: false
                }
            }
        }),
        new BundleAnalyzerPlugin());
}

Exports

Finally we have the configuration object (h) that is being exported from our webpack.config.js. We are configuring webpack to be able to handle: typescript, pug (formerly jade), and scss (both for the site and angular components) files currently. If we need to support other types in the future we will modify this object accordingly. To reiterate the note that was mentioned before, in the rules array we have set up a test for /\.site.scss$/ to specify styles that are to be used in our html pages and not associated with an angular component. A convention that I have adopted for my angular components is for their scss files to end with '.component.scss' which is handled by the /\.component.scss$/ test.

/*********************************
* Exports
*********************************/
module.exports = {
    entry: entry,
    output: output,
    plugins: plugins,
    module: {
        rules: [
            {
                test: /\.ts$/,
                exclude: /node_modules/,
                use: [
                    "ts-loader"
                ]
            },
            {
                test: /\.pug$/,
                exclude: /node_modules/,
                use: [
                    "raw-loader",
                    "pug-html-loader"
                ]
            },
            {
                test: /\.component.scss$/,
                exclude: ["node_modules", "0-bourbon", "1-neat", "2-base"],
                use: [
                    "raw-loader",
                    "postcss-loader",
                    "sass-loader"
                ]
            },
            {
                test: /\.site.scss$/,
                exclude: ["node_modules", "0-bourbon", "1-neat", "2-base"],
                use: ExtractTextPlugin.extract({
                    fallback: "style-loader",
                    use: [
                        "css-loader",
                        "postcss-loader",
                        "sass-loader"
                    ]
                })
            }
        ]
    }
}

PostCss Setup

module.exports = {
    plugins: {
        "autoprefixer": {}
    }
}

Compiling Our Bundles

"scripts": {
    "build": "set NODE_ENV=development&&webpack --progress",
    "build:production": "set NODE_ENV=production&&webpack --progress -p",
    "test": "echo \"Error: no test specified\" && exit 1",
    "watch": "set NODE_ENV=development&&webpack --progress --watch"
}

Finally we can test to make sure that our configuration is working. First we will create our development bundles by typing into our console, making sure we are in the root of the project, npm run build which should output something close to image (k). And now we can create our production build bundles using npm run build:production, shown in image (l).

(k) Webpack development build output.

(l) Webpack production build information.

As we can see in (l) the production size of our vendor bundle comes out to 1.17 MB which of course is large and we would very much like to reduce it. Our first step in reducing the size of the bundle is to analyze the size of each of the imports in our vendor.ts and thanks to the bundle analyzer that we included in our webpack.config.js we can do just that. Once the production build is complete a new window/tab will open in your browser showing a visualization of our bundle sizes (m).

(m) Visualization of the imports contained within our vendor.bundle.min.js file.

import "core-js/es6";
import "core-js/es7/reflect";
import "zone.js/dist/zone";

if (process.env.ENV !== "production") {
    Error["stackTraceLimit"] = Infinity;
    require("zone.js/dist/long-stack-trace-zone");
}

import "@angular/platform-browser";
import "@angular/platform-browser-dynamic";
import "@angular/core";
import "@angular/common";
import "@angular/http";
import "@angular/router";
import "@angular/forms";

import "classlist-polyfill";
import "lodash/each";
import "rxjs";
import "web-animations-js";

As you can see we are now just importing the each function from lodash. I know we will need this function latter on and as our needs change we will return here and add any additional imports required. This change will have a relatively modest effect on the size of our production bundle but once we have some angular code written, so that we can test our changes, we will return to our vendor.ts file and see what other changes we can make.

import each = require("lodash/each");

console.log("Hello World!");

each(["test1", "test2"], (str: string) => {
    console.log(str);
});

Does everything work?

The last thing for us to do is test that everything is working and to do that we simply need to start our web server and navigate to the appropriate address. If you are developing this in Visual Studio we just need to go the Debug menu located in the menubar and choose 'Start Without Debugging' or press Ctrl+F5 otherwise you can navigate a console to the WebUi project and enter 'dotnet run' and press enter. Once the project is built, if you are starting the web server through the console you will need build the project yourself, the website will open in your default browser. The page will be almost blank except for the footer and if we look in the developer tools we should see the output from our main.bundle.js file. In the next article we will actually get to start doing some programming.