Webpack is a popular module bundler, a tool for bundling application source code in convenient chunks and for loading that code from a server into a browser.
It’s an excellent alternative to the SystemJS approach we use throughout the documentation. In this guide we get a taste of Webpack and how to use it with Angular 2 applications.
Table of contents
- Development configuration
- Production configuration
What is Webpack?
Webpack roams over your application source code, looking for
Entries and outputs
We feed Webpack with one or more entry files and let it find and incorporate the dependencies that radiate from those entries. In this example, we start from the application’s root file,
webpack.config.js (single entry)
Webpack inspects that file and traverses its
import dependencies recursively.
Here it sees that we’re importing @angular/core so it adds that to its dependency list for (potential) inclusion in the bundle. It opens @angular/core and follows its network of
import statements until it has build the complete dependency graph from
Then it outputs these files to the
app.js bundle file designated in configuration:
webpack.config.js (single output)
We probably do not want one giant bundle of everything. We’ll likely prefer to separate our volatile application app code from comparatively stable vendor code modules.
We change the configuration so that we have two entry points,
webpack.config.js (two entries)
Webpack constructs two separate dependency graphs and emits two bundle files, one called
app.js containing only our application code and another called
vendor.js with all the vendor dependencies.
[name] in the output name is a Webpack placeholder that is replaced with the entry names.
We need a plugin to make this work; we’llin the chapter.
app.ts earlier. We wrote
vendor.ts such that it imports the vendor modules we need:
webpack.config.js (two entries)
As Webpack encounters
import statements like these …
… it applies the
test RegEx patterns. When a pattern matches the filename, Webpack processes the file with the associated loader.
import file matches the
.ts pattern so Webpack processes it with the
ts (TypeScript) loader. The imported file doesn’t match the second pattern so its loader is ignored.
import matches the second
.css pattern for which we have two loaders chained by the (!) character. Webpack applies chained loaders right to left so it applies the
css loader first (to flatten CSS
url(...) statements) and then the
style loader (to append the css inside <style> elements on the page).
Webpack has a build pipeline with well-defined phases. We tap into that pipeline with plugins such as the
uglify minification plugin:
After that brief orientation, we are ready to build our own Webpack configuration for Angular 2 apps.
Begin by setting up the development environment.
Create a new project folder
Add these files to the root directory:
Many of these files and much of their content should be familiar from other Angular 2 documentation chapters.
Learn about the
package.json in thenpm packages chapter. We require packages for Webpack use in addition to the ones listed in that chapter.
typings.json in the Typescript configuration chapter.
Open a terminal/console window and install the npm packages with
npm install .
We will define separate configurations for development, production, and test environments. All three have some configuration in common. We’ll gather that common configuration in a separate file called
Let’s see the entire file and then walk through it a section at a time:
require statements as such files do.
The configuration exports several objects, beginning with the entries described earlier:
We are splitting our application into three bundles:
- polyfills – the standard polyfills we require to run Angular 2 applications in most modern browsers.
- vendor – the vendor files we need: Angular 2, lodash, bootstrap.css…
- app – our application code.
Load Zone.js early, immediately after the other ES6 and metadata shims.
Our app will
import statements with explicit extensions as in this example:
But most of our
import statements won’t mention the extension at all. So we tell Webpack to resolve module file requests by looking for matching files with
- an explicit extention (signified by the empty extension string,
We could add
.html later if we want Webpack to resolve extension-less files with those extension too.