Loaders and plugins

Webpack only understands JavaScript files as modules. Every other file (.css, .scss, .json, .jpg, and many more) can be transformed into a module while importing. Loaders transform these files and add them to the dependency graph. Loader configuration should be done under module.rules. There are two main options in the loader configuration:

• The test property with a regular expression for testing files the loader should be applied to
• loader or use property with the concrete loader name

module: {
  rules: [
    {test: /.json$/, loader: 'json-loader'},
    {test: /.html$/, loader: 'raw-loader'},
    ...
  ]
}

Note that loaders should be registered in package.json so that they can be installed under node_modules. Webpack homepage has a good overview of some popular loaders (https://webpack.js.org/loaders). For TypeScript files, it is recommended to use the following sequence of loaders in the development mode:

{test: /.ts$/, loaders: ['awesome-typescript-loader', 'angular2-template-loader']}

Multiple loaders are applied from right to left. The angular2-template-loader searches for templateUrl and styleUrls declarations and inlines HTML and styles inside of the @Component decorator. The awesome-typescript-loader is mostly for speeding up the compilation process. For AOT compilation (production mode), another configuration is required:

{test: /.ts$/, loader: '@ngtools/webpack'}

Webpack has not only loaders, but also plugins which take responsibility for custom tasks beyond loaders. Custom tasks could be the compression of assets, extraction of CSS into a separate file, generation of a source map, definition of constants configured at compile time, and so on. One of the helpful plugins used in the seed project is the CommonsChunkPlugin. It generates chunks of common modules shared between entry points and splits them into separate bundles. This results in page speed optimizations as the browser can quickly serve the shared code from cache. In the seed project, we moved Webpack's runtime code to a separate manifest file in order to support long-term caching. This will avoid hash recreation for vendor files when only application files are changed:

plugins: [
  new CommonsChunkPlugin({
    name: 'manifest',
    minChunks: Infinity
  }),
  ...
]

As you can see, configuration of plugins is done in the plugins option. There are two plugins for production configuration yet to be mentioned here. The AotPlugin enables AOT compilation. It needs to know the path of tsconfig.json and the path with module class used for bootstrapping:

new AotPlugin({
  tsConfigPath: './tsconfig.json',
  entryModule: path.resolve(__dirname, '..') + 
               '/src/app/app.module#AppModule'
})

new UglifyJsPlugin({
  compress: {
    dead_code: true,
    unused: true,
    warnings: false,
    screw_ie8: true
  },
  ...
})