First Impressions of Angular CLI
First Impressions of Angular CLI
Using Angular? Check out this list of positives and negatives about the Angular CLI.
Join the DZone community and get the full member experience.Join For Free
Bugsnag monitors application stability, so you can make data-driven decisions on whether you should be building new features, or fixing bugs. Learn more.
Before creating a demo Angular 2 project of my own from scratch, I decided to play with Angular CLI, the command line tool provided by the Angular team to help streamline Angular 2 development.
There are a number of posts and articles out there about Angular CLI, so I'll only share a few personal observations:
- The "--help" option for displaying documentation for the overall list of commands or individual commands is well executed: much more useful and readable than most command line tool documentation.
- I really like the "dry-run" option provided with the commands that generate the application skeleton and config files. It lets you see a list of the files and folders that would otherwise be created by the command without actually creating them, giving you an idea of what to expect.
- The application skeleton structure is a bit different from the structure used in the Quick Start and Tour of Heroes tutorial, moving the "app" directory under an "src" directory. It does this to make room for a "dist" directory parallel to the "src" directory where it can output runtime files for testing and environment-specific distribution builds. I found it interesting that it places the "main.ts" file in that "src" directory instead of the "app" directory.
- I liked how the default development distribution build retains the separate .js and .js.map files for the project code files, while the production build concatenates those files and generally packages your assets to make them more efficient.
- The "ng generate" command is most useful for generating new components. The generated component contains the appropriate @angular/core imports and @Component() metadata, contains an empty constructor method, and implements ngOnInit. Option flags used with the generation command can customize certain aspects of the generated component, such as whether the component uses external HTML and CSS files (the default) verses inline template and inline styles, and whether all of the component assets are bundled in a separate directory. The other files you can generate with the command are mostly empty shells (although generated service files do include the @Injectable() decorator).
- I like that the generated components use the module.id technique to handle relative pathing for the templateUrl and styleUrls properties.
- The CLI documentation refers to the types of files you can generate with "ng generate" as "blueprints". I hope that means that there will one day be an option to add your own personal blueprints into the mix.
- It's interesting that "ng test" starts by creating a development build in the "dist" folder before performing the tests...presumably because the tests are run against that folder. I'm sure there's a reason for doing it that way (making sure everything works after packaging?), but it makes the startup time for testing slow. On the flip-side, once it's started it watches for file changes and re-tests on the fly, so if your coding process involves running unit tests in the background all the time the start-up time penalty is a one-time cost. I also wonder what the implications are for performing unit testing via testing tools in your IDE: would those IDE tools also need to test the build files rather than the .js files in the "app" folder?
Overall, I really like the tool so far, and I look forward to seeing it evolve alongside Angular 2.
Published at DZone with permission of Brian Swartzfager , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.