Reading time: 4 minutes
A disclaimer: I’m not claiming to be an expert here and I’m open to any corrections or input from everyone; this is just what’s worked for me so far. Please enjoy!
As I mentioned in the first post of this series, this series looks out how I have been using Angular 2 with Webpack. The topics in the series are:
- Directory Structure
- Node Modules & NPM Configuration
- Code Linting
- TypeScript Configuration
- Karma Configuration
- Webpack Configuration
- Sample Application
In this article we’ll look at what Node modules to install and how to set up the NPM
Setting Up the
As you may already know, NPM uses the
package.json file to keep track of projects your project depends on. It’s divided up into production dependencies and development dependencies. You can enter the dependencies by hand in the
package.json or use the command-line utility to add them. I opt for the command-line utility because I think it’s easier to let NPM handle it for me.
To start, I always just do a forced NPM initialized, to generate a bare-bones
npm init -f
NOTE: After a co-worker brought it to my attention, I’ve updated the order of installs and been more explicit so that the installs happen with minimal warnings and errors that occur when using NPM version 3 or later.
The development dependencies–and there are quite a few–fall into three main groups:
- Karma: the test runner and any dependencies it uses
- TypeScript: the TypeScript compiler & the Typings utility
- Webpack: our module-loading library and any dependencies it uses
To install them I usually run a single install command, but here I’ll break them down into their two groups and highlight what each does.
npm i -D typescript tslint typings
This command will install the TypeScript compiler and Typings manager as local dependencies. Both of these can also be installed globally (using the
-g flag) but I like having them local so that I can be more assured that my project can build on any system with Node & NPM on it.
npm i -D webpack \
raw-loader node-sass sass-loader ts-loader tslint-loader \
Webpack is obviously needed and also has a plugin system which allows processing on files to be done per filetype.
There’s only a single plugin that I use. It allows me to inject scripts into the
index.html file after they are packaged up. I’ve found this to be a super handy tool. My HTML file is now very minimal, as you can see in the post on Webpack configuration.
Another of these plugins are “loaders” which will convert files, specified by extension, before they’re packaged up. I use one for loading HTML files (
index.html and Angular 2 templates) and the first stage of SASS processing–this is the
raw-loader. The second stage of SASS processing uses the
sass-loader (we also install
node-sass which is a dependency of
For TypeScript I use two loaders, the first is the
tslint-loader which runs the files through the TypeScript linter as part of the “pre-loading” process. The second is the actual TypeScript loader,
ts-loader, processes TypeScript files through the TypeScript compiler.
The last item on the above list is the Webpack Development Server, which is a server so that, as you develop, you can see your site in a browser.
npm i -D karma \
Karma, which runs the tests you’ll write, has a plugin system that makes using it and running tests a breeze. Karma comes with a command to create the configuration file for you (which we’ll do after installing all dependencies). During that process, you can specify the testing framework, where to look for files, and plugins to launch different browsers for testing.
One of those launchers–the one for PhantomJS–has a version 2 that works better with modern development (namely, there are some APIs missing from PhantomJS 1). So I add the version 2 plugin during the install command (
There are also two pre-processors needed to run Webpack before running the tests (
karma-webpack) and create source-maps while the tests are being run (
There are a set of dependencies needed when running in the browser. These can all be installed, however, with a single command:
npm i -S angular2 es6-promise es6-shim \
reflect-metadata rxjs zone.js
Angular 2 depends on five other libraries, which are called out above. They are:
es6-promise: provides a shim for the new Promise API
es6-shim: provides a bunch of shims for newer APIs
reflect-metadata: allows ES7 decorators to be used today
rxjs: provides the Observables Angular 2 requires
zone.js: provides advanced change detection; this is a standalone library by the Angular team
This Is Going to Warn You
The install is going to throw up warnings the first time and whine about the versions of
rxjs. Something like (the following is for Angular 2 beta 17):
├── UNMET PEER DEPENDENCY email@example.com
├─┬ UNMET PEER DEPENDENCY firstname.lastname@example.org
│ └── email@example.com
npm WARN firstname.lastname@example.org requires a peer of email@example.com but none was installed.
npm WARN firstname.lastname@example.org requires a peer of email@example.com but none was installed.
The Angular team seems team to know about it, but it hasn’t been fixed. eta.6 but none was installed. You’ll need to install
rxjs with specific versions, for instance:
npm i -S firstname.lastname@example.org email@example.com
I’ve recently become a big fan of using NPM as the vehicle for my build system. As such, I’ve begun utilizing the
run system to execute any tasks. The
run module looks at keys of the
scripts section of
package.json and executes whatever command the value associated with that key.
Since I’ve only been using this in a non-production system, I don’t have a real “build” script (at this point). But the scripts I’ve been using so far are:
- purpose build the application
npm run test && webpack --config webpack/webpack.prod.js
- purpose: test the code for style errors in code style and patterns
- purpose: run the development server
webpack-dev-server --config webpack/webpack.dev.js
- purpose: unit test the code
karma start src/test/karma/karma.conf.js
Like I said, this is nothing production-ready yet, but it gives a good starting point to start developing. Each of these commands needs a configuration (such as
webpack.dev.js) which will be described later in their individual posts.
That’s it for Now!
In future posts, I’ll show how all of these will be loaded up via Webpack. As for the next post, though, I’ll look at how to install a few TypeScript definitions that are needed for compilation.