A brief overview of this file looks like this:

• Entry, the entry points of the application
• Module.rules, an object that specifies how certain files should be loaded, with what loader
• Plugins, an array of plugins that give us extra functionality during the life cycle of webpack

The entry session specifies that there will be three different bundles: polyfills, vendor, and app. Why these three bundles, you might ask? Well, to have a separate bundle for polyfills makes sense as it is a separate concept from the others. The polyfills bundle ensures our selected browser has all the latest features from ES2015. The vendor bundle is where we place all the libraries that are considered helpers to our app, but not really the app itself. The app bundle is really where our app lives; it contains our business code.

The following code snippet shows what the configuration should look like to create the three previously-mentioned bundles:

entry : {
  'polyfills': './src/polyfills.ts',
  'vendor': './src/vendor.ts',
  'app': './src/main.ts'
}

The module section defines a list of rules. Just as a reminder, rules are about processing certain file extensions. Every rule consists of a test property that defines what file extension to look for. It also consists of the loader property, which points to loaders capable of processing said file extensions. For example, if the file extension is .sass, the loader is capable of compiling the Sass into a CSS file.  

The following code snippet exemplifies how a rule can be set up to handle HTML files:

module : {
  rules : [
    {
      test: /.HTML$/,
      loader: 'HTML-loader'
    }
    // other rules emitted for brevity
  ]
} 

We can see that a regular expression tests for the .html extension and lets HTML-loader handle it. The complete rules list for our project should set up rules for handling TypeScript, assets (images), CSS, and HTML. If we have all that, we are good to go.

We also need to enhance the building process by setting up some plugins, namely: 

• ContextReplacementPlugin
• CommonChunksPlugin 
• HTMLWebpackPlugin

The job of ContextReplacementPlugin is to replace one context for another. But what does that even mean? The most common use case is using require statements that are dynamic, like so:

require('directory/' + name + '.js')

At compile time, webpack is unable to figure out what files to include. To ensure it will work at runtime, it includes everything in that directory. A common case is dealing with translation files. You might have hundreds of files in such a directory, and having all those files included will make the bundle unnecessarily big. So what you do is use said plugin and give it a filter parameter that narrows down the number of files, like so:

new Webpack.ContextReplacementPlugin(
  /directory//, //when trying to resolve a file from this directory
  /(sv-SE|se).js // narrow down the search by only including files
                    that match this
)

The CommonChunksPlugin is used when you are trying to create several bundle files, like so:

entry : {
  'polyfills': './src/polyfills.ts',
  'vendor': './src/vendor.ts',
  'app': './src/main.ts'
}

To avoid that, every single bundle contains the webpack runtime and other common parts; the mentioned plugin can be used to extract the common parts. There are many ways to call this plugin; here is one:

plugins: [ new Webpack.optimize.CommonsChunkPlugin('init') ]

This will create an init.js file.

The webpack generates a lot of files, such as HTML and JavaScript files. You could link to all those files in your index.html, but that becomes quite cumbersome. A better way to handle this is to use HTMLWebpackPlugin, which will inject these link and script tags for you.

Without this plugin, your index.html would look something like this:

<link href="app.css"></link>
<script src="app.bundle.js"></script>
<script src="page1.bundle.js"></script>
<script src="page2.bundle.js"></script>
<script src="common.bundle.js"></script>

You get the idea, using this plugin is pretty much a must, at least if you want to make sure to keep index.html in sync with your solution and avoid unnecessary typing by having to add/alter script tags.

What we need to do to make this plugin work is to point to where the script and link tags need to be injected, like so:

new HtmlWebpackPlugin({
  template: 'src/index.HTML'
})

So far, we have covered what bundles are created, what rules need to be set up to handle all different file extensions, and lastly what plugins are needed. This is the core of the webpack setup. However, the configuration needs to differ a bit depending on whether we are dealing with a development environment or a production environment.