Angular CLI
Angular CLI is a command line tool that you use to initialize, develop, scaffold, and maintain Angular applications.
What’s New
The 7.1.2 release of Angular is here! This is a major release spanning the entire platform, including the core framework, Angular Material, and the CLI with synchronized major versions. This release contains new features for our tool chain, and has enabled several major partner launches. The new version depends on the latest version of TypeScript (v3.1) and Node 10.
Prerequisites
In order to install Angular CLI, the following should be installed in the development environment:
Installing Angular CLI
Install the CLI using the npm
package manager:
npm install -g @angular/cli
If you already have angular cli then for updating it to latest version:
npm uninstall -g angular-cli
npm cache clean or npm cache verify (if npm > 5)
npm install -g @angular/cli@latest
you can check version of angular cli by
ng --version
If you want to update your project to latest angular follow this link: https://update.angular.io/
Create a new project
Creating a new Angular Project is very easy by using Angular CLI :
ng new {project-name}
It will ask some questions:
Would you like to add Angular routing?
Which stylesheet format would you like to use?
CSS
SCSS [ http://sass-lang.com ]
SASS [ http://sass-lang.com ]
LESS [ http://lesscss.org ]
Stylus [ http://stylus-lang.com ]
That’s the default usage of the command and creating a new project folder with {project-name}
. The project which is created in that folder is containing:
- The default Angular project
- All dependencies installed in node_modules folder
- Testing files for each components
src/app
directory: - This directory contains source code, css, and html files.
- This is where most of the work will be done.
app.module.ts
: MainNgModule
for the application. - Everything must belong to a module (even other modules).
main.ts
: Bootstraps your application.index.html
: Main html file for your application.
you can serve the application in development mode by using:
ng serve --open
will give you the following output,
and open browser on http://localhost:4200
Generating A Routing Module App
By using command line parameter --routing
we’re able to specify that a routing module should be added to the Angular application which is being generated:
ng new {project-name} --routing
Executing this command generated an additional file app-routing.module.ts in the `src/app` folder. This file contains an empty default implementation of a Angular routing module. This module is also added to AppModule, so that you can directly add route configuration to the routes property.
Generate a new component
ng generate component {{component-name}} eg: ng generate component user
Add routing for new component
First inserted router-outlet in file app.component.html so other components will render inside this.
<router-outlet></router-outlet>
for our new user component add a new route in app-routing.module.ts:
import { UserComponent } from './user/user.component';
const routes: Routes = [ { path: 'user', component: UserComponent }];
You can now access URL http://localhost:4200/user.
Build Application
Angular app can be build in two ways:
- Development Mode:
ng build
- Production Build:
ng build --prod
This command will cause the CLI to build your application and place the output in a directory called “dist” (by default).
Angular ClI: Important Command
- Dry Run: Sometimes you want to try out, what a command does, before it actually does something. Specifically if you are new to the CLI, the dry-run option will be very useful.
This option will stop the CLI from making any changes to the file system. Instead it will print everything it would have done to the console.
That way you can check if the command actually does what you thought it does, before it causes any harm.ng new example --dry-run
You can append –dry-run to almost all of the angular-cli commands. - Skip Test: We can tell the CLI not to create test by using the –skip-tests option:
ng new example --skip-tests
Generate Commands:
ng generate {{what_need_to_generate}} {{name}}
You can create a whole bunch of different angular-blueprints by replacing {{what_need_to_generate}} by one of the following:
1. class
2. directive
3. enum
4. guard
5. interface
6. module
7. pipe
8. service
More details you can find here : https://github.com/angular/angular-cli/wiki/generate
To register service, component, etc. with a module : To register our service, component, etc. with a module we can use –module option. We can also use its alias –m.
ng generate service myservicename -module=app.module
Checking the Quality of Our Code
1. Linting Code:
// Lint the project against the official Angular style guide using Codelyzer.
=> ng lint // Use the stylish output format to display linting errors.
=> ng lint --format stylish// Try to automatically fix linting errors.
=> ng lint --fix
2. Running the tests:
=> ng test
//Run the unit tests and watch the files.
=> ng test --single-run// Run the unit tests once and exit.
=> ng test --code-coverage// Output code coverage files in the ./coverage directory.
=> ng test --browsers PhantomJS// Use PhantomJS to run the tests.
=> ng e2e// Run e2e tests.
=> ng e2e --element-explorer//Allow debugging by enabling Protractor's Element Explorer.
Configuring application environments
You’re building an app that talks to the API for example, you’ll want to use your http://localhost:3000 during development and then your live http://your-host-addess in production. It’s easy to do in Angular using the environment.ts file.
Angular CLI projects already use a production environment variable to enable production mode when in the production environment:
// main.ts
// ... if (environment.production) { enableProdMode();}
// ...
And you’ll also notice that by default in the /src/environment
folder you have an environment file for development and one for production. Let’s say we want to be a different api depending if we’re in development or production mode:
// environment.ts
export const environment = {
production: false,
baseApiUrl: 'http://localhost:3000'
};
//environment.prod.ts
export const environment = {
production: true,
baseApiUrl: 'http://myServer.com'
};
And in our component/service all we have to do in order to access the variable is the following:
import { environment } from '../environments/environment';
export class ApiService {
baseApiUrl: string = environment.baseApiUrl;
}
More details: https://angular.io/guide/build#configuring-application-environments
Proxy To Backend (CORS Error)
When working on the frontend of a project using angular, mainly times the backend api’s are not hosted on localhost or the same domain. This causes CORS error in browser and api’s don’t work. To fix the CORS issue,
Create a file proxy.conf.json next to the package.json file. Edit this file and paste:
{
"/posts":
{
"target": "https://example.com",
"secure": true,
"pathRewrite": { "^/api": "" },
"changeOrigin": true
}
}
With this any api request with host api/ will be redirected to example.com
You also need to update package.json script for this:
"start": "ng serve --proxy-config proxy.conf.json"
You can run this proxy server by using :
pm start or ng serve --proxy-config proxy.conf.json
More details : https://github.com/angular/angular-cli/blob/master/docs/documentation/stories/proxy.md
Analyzing bundle size with the Angular CLI and Webpack
Having a high performance web app is always top priority. With Angular there is no exception. But with our web apps becoming ever so increasingly complex how we can know what gets bundled into our apps? No one wants to send too much JavaScript all at once to slow app.
Large JavaScript bundles are lose user engagement. Also slow the download but also took more time to evaluate and execute. For our apps to stay fast, we need to make sure they stayed small.
For checking bundle size we need to build out app in production by using CLI:
ng build --prod --stats-json
With these bundled and packaged files, we can deploy our Angular app on any server.
The --prod
flag told the CLI to build our app for production.
The --stats-json
flag told CLI will generate a stats.json
file in the dist with our bundles. This stats file has all kinds of useful data about our application bundles. If you look at the file its quite a bit of data so we need a tool to help digest and understand this data.
The stats.json file is specifically is a feature of Webpack. Webpack is the JavaScript package/bundling tool the CLI uses. With this stats.json file Webpack generated for us, we can use a few different tools to understand our app.
The tool we will use is the Webpack bundle analyzer. Webpack bundle analyzer is an npm package you can use in a Webpack config or just as a command line tool. For our use case, we will simply use the command line tool.
To use this tool use the following steps:
- Install via npm to your CLI project:
npm install --save-dev webpack-bundle-analyzer
- Once installed add the following entry to the npm scripts in the
package.json
"bundle-report": "webpack-bundle-analyzer dist/stats.json"
- Once added run the following command:
npm run bundle-report
this will open your browser http://127.0.0.1:8888/ with output like:
Each color in chart represents an individual bundle. In our application, we have three bundles
1. Vendor bundle: that contains all the library code
2. Polyfill bundle
3. Main application code bundleWe can further inspect each bundle and see the uncompressed and compressed sizes. This allows us to quickly determine what parts of our code are the largest and we can also decide whether we need to break our app up further using Lazy Loading.
As our apps grow, we can just runnpm run bundle-report
to closely monitor our dependencies and how they affect the bundle sizes keeping our apps lightweight and fast!