The Angular CLI is one of the most powerful tools in the web ecosystem, transforming complex workspace setup into a single command.
1The Power of 'ng'
The Angular CLI (ng) is more than just a project generator. It is a full lifecycle tool. You use it to generate components, run unit tests, perform end-to-end testing, and build your application for production. By following the CLI's standard project structure, you ensure that any other Angular developer can jump into your project and understand exactly where everything is.
2Project Anatomy
When you run ng new, Angular sets up a sophisticated environment. The angular.json file is the brain of the workspace, defining how the app is built and served. The src/app folder is the heart, containing the logic and views. This 'Convention over Configuration' approach means you spend less time setting up build tools and more time writing features.
3Step-by-Step Breakdown
Time to get our hands dirty. The best way to start an Angular project is through the Angular CLI (Command Line Interface). It handles everything from generation to deployment.
First, you need to install the CLI globally using npm. This gives you the 'ng' command in your terminal.
Once installed, creating a new project is as simple as running 'ng new' followed by your project name. The CLI will ask if you want routing and which style format to use.
Checkpoint: What is the primary command used to create a new Angular project from the terminal?
- →angular
- →ng
- →npm
The CLI generates a structured workspace. The 'src' folder is where you'll spend 99% of your time. Inside 'app', you'll find your components, modules, and services.
To see your app in action, use 'ng serve'. This starts a local development server, usually at localhost:4200, with hot-reloading enabled.
Your browser will automatically open to the Angular starter page. You're now running a live, production-ready framework setup!
Checkpoint: What is the default port used by the Angular development server (ng serve)?
- →3000
- →4200
- →8080
Congratulations! You've successfully created and launched your first Angular workspace. In the next chapter, we'll start building our first real components.
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1The CLI's Generated Starter App Is a Reasonable Accessibility Baseline, Not a Guarantee
`ng new` scaffolds a valid, semantic starting `index.html` and app shell, but everything built on top of it is only as accessible as the components a team actually writes — the generator gives you a clean starting point, not an accessibility guarantee for the whole app.
2Add Angular's `@angular/cdk/a11y` Package Early for Complex Custom Components
The Component Dev Kit's accessibility module (focus trapping, live announcer, ARIA descriptors) is far easier to adopt from the start of a project than to retrofit onto components already built without it.
SEO Implications
- 1
Decide on SSR (Angular Universal) at Project Creation Time if SEO Matters
Adding `ng add @angular/ssr` at the very start of a project is dramatically simpler than retrofitting server-side rendering onto a large, mature client-side-only codebase later — if the app's content needs to be indexable, make this decision during initial setup.
- 2
The CLI's Production Build Configuration Is Foundational to Good Core Web Vitals
`ng build` in production mode applies tree-shaking, minification, and differential loading out of the box — understanding and correctly using these CLI defaults from day one avoids having to retroactively optimize a bloated bundle later.
Best Practices
Use `ng generate` for New Components Instead of Manually Creating Files
The generator schematic creates a component with the correct file structure, boilerplate, and registration (or standalone imports) automatically, eliminating an entire class of 'forgot to register this in a module' errors from manual file creation.
Decide Between Standalone and NgModule Architecture at Project Creation, Not Mid-Project
While both can technically coexist, committing to one pattern from the start (the CLI defaults to standalone in modern Angular versions) keeps the codebase's architecture consistent and easier for new team members to learn.
Frequent Bugs
A component created by manually copy-pasting files from another component doesn't work correctly.
Manual copying often misses required updates like the component's `selector`, class name, and correct registration/import — use `ng generate component` instead, which handles all of this correctly and consistently every time.
Enabling server-side rendering on an existing, mature Angular project surfaces dozens of errors about undefined `window`/`document`.
This is expected when SSR is added retroactively to code that was written assuming a browser-only environment — every browser-only API access needs to be guarded with `isPlatformBrowser()` checks. This is exactly the retrofitting cost that's dramatically smaller if SSR is decided upon at project creation instead.
Real-World Examples
Project Creation With SSR Decided Upfront
A new marketing-facing Angular project enables server-side rendering at creation time, avoiding the much larger retrofit cost of adding it after the app has grown and accumulated browser-only assumptions throughout its codebase.
ng new my-app --ssr
cd my-app
ng build && ng run my-app:serve-ssr