Welcome to part 2 of our ongoing series on what's new in Angular 6. Today, we will focus on the changes to the Command Line Interface, or CLI.
History of The Angular CLI
First a quick bit of history. The Angular CLI was created in response to the complications of setting up a modern web application. When Angular 2 was released, the "best" way to get started with an application was to clone the Angular project's angular-seed repo from GitHub. Hardly ideal, and not very configurable. The CLI was developed to give programmers a highly customizable "tool to initialize, develop, scaffold and maintain Angular applications" (quoted from the Angular CLI wiki).
Initially, the CLI was not developed on the same schedule as Angular itself. Up until Angular 6, the CLI was not in version harmony with Angular and was sometimes a few patch versions (or even a minor version) behind. That is no longer the case with Angular 6. The CLI versioning has caught up with the rest of Angular and is now 6.x.x.
The changes to the CLI came in two distinct areas: commands, and the new workspaces concept.
What Are Workspaces?
In short, workspaces are collections of Angular projects. Previously, an Angular application was managed at, well, the application level. Now, you can use the CLI to manage multiple projects.
The immediate practical effect is that the .angular-cli.json file has been replaced with the new angular.json file. The specs for the file are listed here (https://github.com/angular/angular-cli/wiki/angular-workspace). Of note is the configurations option, which should let you store workspace-wide and per-project configurations. This will be a boon for those who do not want to specify the same command-line options repeatedly.
What Are Some of the Changes to Commands in Angular 6?
The eject command has been disabled. According to the release notes, this is because the eject command is not compatible with the new angular.json file yet. This will be fixed in an upcoming update.
The CLI has added the ng add and ng update commands. These commands are intended to make it easier for developers to add and update dependencies in their projects. For example, say you discover a new and terrific third-party Angular component that you want to include in your project. Unfortunately, after a few months, anytime you run npm, it tells you that the spiffy new component is out of date, and by a full version number to boot! You might be worried that if you update the component, it may break something (as indicated by the fact that the major version number incremented, which implies a break in backwards compatibility).
The fix: If you had added the component with ng add, you would be able to use ng update to update the component. Between Angular and the component's maintainer(s), the CLI hopes to deliver you a seamless and painless upgrade process.
Implementing ng add and ng update
Let's try them out. First, I'm going to use ng add to add @angular/material to my current Angular project:
Ok, pretty good! The package was installed, the peer dependency was not (par for the course, since ng add uses npm or yarn under the hood and they both do not install peer dependencies either). After the package install ng add ran the schematics associated with @angular/material and updated package.json, angular.json, and several other files. Pretty great!
What Are Schematics?
Wait, schematics? What are those? Schematics are intended to give you greater control over what CLI commands do. If you wanted to change what the standard template for a component looked like, you would use a schematic. But you could also use a schematic to control library updates or manage the packaging or deployment process. With ng add and ng update, you should be able to write schematics-based code to control what happens when you update or install a given library or even libraries in general.
Here's the catch: ng add and schematics are brand-new features. What happens, for instance, when we go to add in that peer dependency on @angular/cdk?
It appears that @angular/cdk has not been updated to use schematics (yet). Thankfully, we can resolve this with a call to our package manager:
I added @angular/material again to see if it picked up that @angular/cdk had been installed.
At some point in the future, we will want to update our library dependencies. This is where ng update comes in. If I run ng update in my newly-minted Angular app, I get a rather benign message:
Obviously, since I created this application yesterday there are no library updates to worry about. Let's try this on an older project, perhaps the ngmodelupdate-old project from the previous article.
That is, indeed, accurate. That application was explicitly written for Angular 5.x, so it needs some updates. First up, @angular/core:
Perhaps it is not fair to expect a feature introduced with Angular 6 to work on Angular 5. I would expect ng update to work well with Angular going forward. For now, you will be better served updating from Angular 5 to Angular 6 manually.
Version updating has been a complicated issue in JavaScript and in computer programming in general. While both ng addand ng update take advantage of your underlying package manager (npm or yarn), I would be very cautious about depending on these new features in a large and complex project. Introduce them slowly. Try them out in some areas where either introducing or subsequently backing out changes will be easier and less likely to provoke a great deal of work. I am eager to see how these features develop.
Author: John Paxton, one of Accelebrate's instructors.
Accelebrate offers private Angular training for groups and instructor-led online Angular classes for individuals. Visit /angular-training to see the full list of courses.
John is a trainer, programmer and consultant with more than twenty years of experience in JavaScript, Java, SQL, web applications, and other technologies. He has written several courses and one book and has taught on six continents.
