Setting up an application with Angular CLI

In tandem with the Angular 2 framework, the Angular team also supports a build tool that can create, build, and run an Angular 2 application right out of the box. What's more, it includes a generator that can create style-guide-compliant files and directories for various application pieces from the command line.

Note

The code, links, and a live example of this are available at .

Getting ready

Angular's CLI is an npm module. You'll need to have Node.js installed on your system—v7.0.0 or later works as a suitable recent release that's compatible with the Angular CLI.

Tip

There is another option you have: manage your Node environments with nvm, the Node version manager. This gives you a transparent wrapper that can separately manage environments with the Node version as well as the installed npm packages in that environment. If you've ever dealt with messiness involving sudo npm install -g, you will be delighted by this tool.

Once Node is installed (and if you use nvm, you've selected which environment to use), install the Angular CLI:

 npm install -g angular-cli

How to do it...

Angular CLI comes ready to generate a fully working Angular 2 application. To create an application named PublisherApp, invoke the following command:

 ng new publisher

The Angular CLI will dutifully assemble all the files needed for a minimal Angular 2 TypeScript application, initialize a Git repository, and install all the required npm dependencies. The created file list should look as follows:

 create README.md createsrc/app/app.component.css createsrc/app/app.component.html createsrc/app/app.component.spec.ts createsrc/app/app.component.ts createsrc/app/app.module.ts createsrc/app/index.ts createsrc/app/shared/index.ts createsrc/environments/environment.prod.ts createsrc/environments/environment.ts createsrc/favicon.ico createsrc/index.html createsrc/main.ts createsrc/polyfills.ts createsrc/styles.css createsrc/test.ts createsrc/tsconfig.json createsrc/typings.d.ts create angular-cli.json create e2e/app.e2e-spec.ts create e2e/app.po.ts create e2e/tsconfig.json create .gitignore create karma.conf.js createpackage.json create protractor.conf.js   create tslint.json

Use cd publisher to move into the application's directory, which will allow you to invoke all the project-specific Angular CLI commands.

Running the application locally

To run this application, start up the server:

 ng serve

The default application page will be available on localhost:4200.

Testing the application

To run the application's unit tests, use this:

 ng test

To run the application's end-to-end tests, use this:

 ng e2e

How it works...

Let's roughly go through what each of these files offer to you:

Project configuration files

angular-cli.json is the configuration file specifying how the Angular CLI should bundle and manage your application's files and directories.
package.json is the npm package configuration file. Inside it, you'll find scripts and command-line targets that the Angular CLI commands will tie into.

TypeScript configuration files

tslint.json specifies the configuration for the tslint npm package. The Angular CLI creates for you a lint command for .ts files with npm run lint.
src/tsconfig.json is part of the TypeScript specification; it informs the compiler that this is the root of the TypeScript project. Its contents define how the compilation should occur, and its presence enables the tsc command to use this directory as the root compilation directory.
e2e/tsconfig.json is the end-to-end TypeScript compiler configuration file.
src/typings.d.ts is the specification file for the typings npm module. It allows you to describe how external modules should be wrapped and incorporated into the TypeScript compiler. This typings.d.ts file specifies the System namespace for SystemJS.

Test configuration files

karma.conf.js is the configuration file for Karma, the test runner for the project
protractor.conf.js is the configuration file for Protractor, the end-to-end test framework for the project
src/test.ts describes to the Karma configuration how to start up the test runner and where to find the test files throughout the application

Core application files

src/index.html is the root application file that is served to run the entire single-page application. Compiled JS and other static assets will be automatically added to this file by the build script.
src/main.ts is the top-level TypeScript file that serves to bootstrap your application with its AppModule definition.
src/polyfills.ts is just a file that keeps the long list of imported polyfill modules out of main.ts.
src/styles.css is the global application style file.

Environment files

src/environments/environment.ts is the default environment configuration file. Specifying different environments when building and testing your application will override these.
src/environments/environment.prod.ts is the prod environment configuration, which can be selected from the command line with --prod.

AppComponent files

Every Angular 2 application has a top-level component, and Angular CLI calls this AppComponent.

src/app/app.component.ts is the core TypeScript component class definition. This is where all of the logic that controls this component should go.
src/app/app.component.html and src/app/app.component.css are the templating and styling files specific to AppComponent. Recall that styling specified in ComponentMetadata is encapsulated only to this component.
src/app/app.module.ts is the NgModule definition for AppComponent.
src/app/index.ts is the file that informs the TypeScript compiler which modules are available inside this directory. Any modules that are exported in this directory and used elsewhere in the application must be specified here.

AppComponent test files

src/app/app.component.spec.ts are the unit tests for AppComponent
e2e/app.e2e-spec.ts are the end-to-end tests for AppComponent
e2e/app.po.ts is the page object definition for use in AppComponent end-to-end testing

There's more...

When looking at the entire project codebase, the bulk of the files break down into four categories:

Files that are sent to the browser: This includes your uncompiled/unminified application files and also the compiled/minified files. When developing your application, you want to be able to test your application locally with uncompiled files. You also want to be able to ship your application to production with compiled and minified files, which optimizes browser performance. The uncompiled/unminified files are collected by the build scripts, to be combined into the compiled/minified files.
Files used for testing: The test files themselves are usually sprinkled throughout your application and are not compiled. This category also includes configuration files and test scripts that control what actually happens when you run the tests and where the test runners can find the test files in your project directory.
Files that control your development environment: Depending on your setup, your single-page application may run by itself (with no backend codebase), or it may be built alongside a substantial backend codebase that exposes APIs and other server-side behavior. Quickstart repositories or application generators (such as Angular CLI) usually provide you with a minimal HTTP server to get you off the ground and serve your static assets to the browser. How exactly you run your development environment will vary, but the files in this category manage how your application will work both locally and in production.
Files that compile your application: The files you edit in your code editor of choice are not the ones that reach the browser in a production application. Build scripts are usually set up to combine all your files into the smallest and fewest files possible. Frequently, this will mean a single compiled JS and compiled CSS file delivered to the browser. These files will minify your codebase, compile TypeScript into vanilla JavaScript, select environment files and other context-specific files, and organize file includes and other files and module dependencies so that your application works when it's compiled. Usually, the files they create will be dumped into a dist directory, which will contain files that are served to the browser in production.