HomeAngularAngular CLI 7.1.2 – Whats New and Project Setup

Angular CLI 7.1.2 – Whats New and Project Setup

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:

  1. Would you like to add Angular routing?
  2. Which stylesheet format would you like to use?

     

    1. CSS
    2. SCSS [ http://sass-lang.com ]
    3. SASS [ http://sass-lang.com ]
    4. LESS [ http://lesscss.org ]
    5. 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: Main NgModule 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:

  1. Development Mode:
    ng build
  1. 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 RunSometimes 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-jsonflag 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:

  1. Install via npm to your CLI project:
    npm install --save-dev webpack-bundle-analyzer
  2. Once installed add the following entry to the npm scripts in the package.json
    "bundle-report": "webpack-bundle-analyzer dist/stats.json"
  3. 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 bundle

    We 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 run npm run bundle-report to closely monitor our dependencies and how they affect the bundle sizes keeping our apps lightweight and fast!

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: