Angular applications and Angular itself depend upon features and functionality provided by a variety of third-party packages. These packages are maintained and installed with the Node Package Manager (npm).
Node.js and npm are essential to Angular development.
Get them now if they're not already installed on your machine.
Verify that you are running node
v4.x.x or higher and npm
3.x.x or higher
by running the commands
node -v and
npm -v in a terminal/console window.
Older versions produce errors.
We recommend a comprehensive starter-set of packages as specified in the
sections of the package.json file
installed as described during Setup.
You can use other packages but we recommend this particular set to start with because (a) they work well together and (b) they include everything you'll need to build and run the sample applications in this series.
Note: A cookbook or guide page may require an additional library such as jQuery.
You'll install more than you need for QuickStart. No worries! You only serve to the client those packages that the application actually requests.
This page explains what each package does. You can make substitutions later to suit your tastes and experience.
dependencies and devDependencies
package.json includes two sets of packages,
dependencies and devDependencies.
The dependencies are essential to running the application.
The devDependencies are only necessary to develop the application.
You can exclude them from production installations by adding
--production to the install command, as follows:
dependencies section of
Features - Feature packages give the application framework and utility capabilities.
Other - Other libraries that support the application such as
bootstrapfor HTML widgets and styling.
@angular/core - Critical runtime parts of the framework needed by every application.
Includes all metadata decorators,
Directive, dependency injection, and the component lifecycle hooks.
@angular/common - The commonly needed services, pipes, and directives provided by the Angular team.
@angular/compiler - Angular's Template Compiler.
It understands templates and can convert them to code that makes the application run and render.
Typically you don’t interact with the compiler directly; rather, you use it indirectly via
platform-browser-dynamic or the offline template compiler.
@angular/platform-browser - Everything DOM and browser related, especially the pieces that help render into DOM. This package also includes the bootstrapStatic method for bootstrapping applications for production builds that pre-compile templates offline.
@angular/platform-browser-dynamic - Includes Providers and a bootstrap method for applications that compile templates on the client. Don’t use offline compilation. Use this package for bootstrapping during development and for bootstrapping plunker samples.
@angular/http - Angular's http client.
@angular/router - Component router.
@angular/upgrade - Set of utilities for upgrading Angular 1 applications.
system.js - A dynamic module loader compatible with the ES2015 module specification. Other viable choices include the well-regarded webpack.
Your future applications are likely to require additional packages that provide HTML controls, themes, data access, and various utilities.
Angular requires certain polyfills in the application environment.
Install these polyfills using the npm packages that Angular lists in the peerDependencies section of its
You must list these packages in the
dependencies section of your own
For background on this requirement, see Why peerDependencies?.
core-js - Patches the global context (window) with essential features of ES2015 (ES6). You may substitute an alternative polyfill that provides the same core APIs. When these APIs are implemented by the major browsers, this dependency will become unnecessary.
reflect-metadata - A dependency shared between Angular and the TypeScript compiler. You can update a TypeScript package without upgrading Angular, which is why this is a dependency of the application and not a dependency of Angular.
Other helper libraries
angular-in-memory-web-api - An Angular-supported library that simulates a remote server's web api without requiring an actual server or real http calls. Good for demos, samples, and early stage development (before we even have a server). Read about it in the Http Client page.
bootstrap - Bootstrap is a popular HTML and CSS framework for designing responsive web apps. Some of the samples improve their appearance with bootstrap.
The packages listed in the devDependencies section of the
package.json help you develop the application.
You don't have to deploy them with the production application although there is no harm in doing so.
concurrently - A utility to run multiple npm commands concurrently on OS/X, Windows, and Linux operating systems.
lite-server - A light-weight, static file server, by John Papa with excellent support for Angular apps that use routing.
typescript - the TypeScript language server, including the tsc TypeScript compiler.
@types/* - TypeScript definition files. Learn more about it in the TypeScript Configuration chapter.
There isn't a peerDependencies section in the QuickStart
But Angular has a peerDependencies section in
its package.json, which has important consequences for your application.
It explains why you load the polyfill dependency packages in the QuickStart
and why you'll need those packages in your own applications.
An explanation of peer dependencies follows.
Packages depend on other packages. For example, your application depends on the Angular package.
Two packages, "A" and "B", could depend on the same third package "C". "A" and "B" might both list "C" among their dependencies.
What if "A" and "B" depend on different versions of "C" ("C1" and "C2"). The npm package system supports that.
It installs "C1" in the
node_modules folder for "A" and "C2" in the
node_modules folder for "B".
Now "A" and "B" have their own copies of "C" and they run without interferring with one another.
But there is a problem. Package "A" may require the presence of "C1" without actually calling upon it directly. "A" may only work if everyone is using "C1". It falls down if any part of the application relies on "C2".
The solution is for "A" to declare that "C1" is a peer dependency.
The difference between a
dependency and a
peerDependency is roughly this:
A dependency says, "I need this thing directly available to me."
A peerDependency says, "If you want to use me, you need this thing available to you."
package.json specifies several peer dependency packages,
each pinned to a particular version of a third-party package.
We must install Angular's peerDependencies ourselves.
When npm installs packages listed in your
it also installs the packages listed within their packages
The process is recursive.
However, as of version 3, npm does not install packages listed in peerDependencies sections.
This means that when your application installs Angular, npm doesn't automatically install the packages listed in Angular's peerDependencies section.
Fortunately, npm issues a warning (a) When any peer dependencies are missing, or (b) When the application or any of its other dependencies installs a different version of a peer dependency.
These warnings guard against accidental failures due to version mismatches. They leave you in control of package and version resolution.
It is your responsibility to list all peer dependency packages among your own devDependencies.
The future of peerDependencies
The Angular polyfill dependencies are hard requirements. Currently, there is no way to make them optional.
However, there is an npm feature request for "optional peerDependencies," which would allow you to model this relationship better. When this feature request is implemented, Angular will switch from peerDependencies to optionalPeerDependencies for all polyfills.