Last Friday (3/24) the Angular CLI was released as version 1.0. Our team has been using the CLI for production Angular applications since last August. As the numerous beta and RC versions were released we would update our applications accordingly. There were a few bumps along the way when a new release introduced a breaking change, but for the most part the upgrade path was pretty smooth.
I actually wrote about the Angular CLI a few months ago when it was still in beta. Now that the CLI has reached 1.0 status, I thought it would be a good time to review how we are using the CLI, and what we see as the main benefits.
Standard Project Structure
ng new project-name
command ensures that new projects have the same layout. This provides two benefits:
- No time is wasted at the beginning of each project deciding how to organize the application structure.
- All of our Angular applications look the same so it is easier to have developers work on multiple projects without spending time figuring out how each one is setup.
Fully Wired Tool Chain
The number of tooling options that exist in the front end development space has grown over the last few years to the point that it is not practical to create a new project from scratch. There are too many decisions to make and too much setup and configuration to get it all working. The project that is created by the CLI has tooling included and configured for unit testing, end-to-end testing, bundling, minification, linting, environment specific builds, a web server, and more.
Follows the Style Guide
The Angular documentation is very good (https://angular.io/), and it also includes a style guide. The CLI follows the style guide with respect to application structure, modules, routing, component and file naming conventions, and testing.
After an application is created using
ng new project-name
, the CLI can still be used to create components, modules, classes, enums, interfaces, directives, guards, pipes, and services using the
ng generate component|service|directive|module|pipe|guard
command. Using the CLI to generate these parts of the application ensures that a consistent naming standard is used. Also, components and services created by the CLI have a spec file created with a simple passing “smoke test”. I find that I am much more likely to write tests for a component or service since the test runner is already wired up for you.
Testing and Linting
In general, a linter checks your code for readability, maintainability, and potential functionality errors. For Typescript, the linter is called tslint. In a CLI generated project, tslint is setup and the
command runs the linter and displays a list of violations. The tslint rules are defined in a tslint.json file and can be modified to fit your team’s needs.
For testing, karma and jasmine are configured as the test runner and framework respectively. There is also a code coverage tool which can be optionally run along with the tests.
Finally, end-to-end (e2e) tests are setup to run with protractor.
The Angular CLI continues to be an important part of our Angular application development toolset and it continues to evolve along with the Angular framework. The best place to learn more about the Angular CLI is at the Angular CLI site.