From Empty Folder to Running App: Setting Up a Modern Angular 22 Project

Before you can learn components, templates, services or routing in Angular, you need a project that actually runs on your machine. Getting there involves a handful of tools, a scaffolding command and a folder layout that looks quite different from what many older tutorials show. This walkthrough takes you from a clean machine to a running Angular 22 application, explains what each tool does, and shows how the generated pieces connect so the rest of the framework has somewhere to land.

What you need before you start

A local Angular setup rests on four things: Node.js, the Angular CLI, a code editor (Visual Studio Code is a common choice) and a terminal. There is no need to install TypeScript on its own; creating a project pulls in Angular, TypeScript and every other required package automatically.

Version compatibility matters. At the time of writing, Angular's version compatibility reference lists Node.js v22.22.3 or newer as the minimum for Angular 22, alongside newer supported release lines. These ranges shift between Angular releases, so check the current compatibility table on angular.dev before you install anything.

Step 1: install Node.js and npm

Angular builds browser applications, so it is fair to ask why a server-side runtime is involved. The answer is tooling. Node.js lets JavaScript run outside the browser, and the Angular CLI, the compiler, the development server and the test tooling are all JavaScript programs that need it. Node.js also ships with npm, the package manager Angular uses to install your project's dependencies.

Download an installer from the official Node.js website. Once it finishes, open a terminal (or Command Prompt on Windows) and confirm the runtime is on your path:

node --version

The output should be a version string along these lines:

v22.22.3

Then confirm npm is available too:

npm --version

If both commands print a version number, the foundation is in place. Resist the urge to keep whatever old Node.js version happens to be installed just because an older tutorial worked with it. Each Angular major has its own supported Node.js range, and a mismatch tends to show up as confusing install or build errors rather than a clear message. Tools such as nvm or fnm make it easy to switch Node.js versions per project if you need several.

Step 2: understand what the Angular CLI does

The next tool is the Angular CLI (Command Line Interface). It is the main way you create and manage Angular applications: it scaffolds new projects, generates components and services, runs the development server, produces production builds, runs tests and handles many other routine tasks. Rather than hand-writing dozens of files and wiring up a build configuration yourself, you let the CLI produce a working, conventional starting point and then build on top of it.

Step 3: install the Angular CLI globally

Install the CLI with npm:

npm install -g @angular/cli@22

Each part of the command has a job. npm install installs a package. The -g flag installs it globally, which makes the command available from any folder rather than only inside one project. The @22 suffix pins the install to the Angular 22 major line, so you get a CLI that matches the framework version you intend to use.

When the installation completes, verify it:

ng version

This prints details about the installed CLI and related packages. Notice that the command is not angular but ng, the executable the CLI package puts on your path. You will type it constantly:

ng

A practical note: once a project exists, its package.json also contains a local copy of the CLI, and running ng inside the project folder uses that local version. The global install is mainly there so you can run ng new before any project exists.

Step 4: scaffold your first application

Move to the folder where you keep your projects, for example:

cd Desktop

Then ask the CLI to create a new application:

ng new my-first-angular-app

The final argument, my-first-angular-app, becomes the project and folder name; any valid name works. ng new is interactive, so it may ask a few questions about how to configure the project, such as which stylesheet format to use. The exact prompts change as Angular evolves, so do not be surprised if yours differ from a screenshot or an older guide.

For a first project, accepting the recommended defaults is a sensible choice. Current defaults generate an application based on the standalone API and use the shorter, modern file naming convention you will see in a moment. When the command finishes, a new folder exists:

my-first-angular-app/

Step into it:

cd my-first-angular-app

Step 5: find your way around the generated files

Open the folder in your editor. A freshly generated project looks roughly like this:

my-first-angular-app/
│
├── .vscode/
│
├── node_modules/
│
├── public/
│
├── src/
│   ├── app/
│   │   ├── app.ts
│   │   ├── app.html
│   │   ├── app.css
│   │   └── app.spec.ts
│   │
│   ├── index.html
│   ├── main.ts
│   └── styles.css
│
├── angular.json
├── package.json
├── tsconfig.json
└── README.md

A quick orientation to the most important entries:

• src/main.ts is the entry point that bootstraps the application.
• src/index.html is the single HTML page the browser loads; Angular renders into it.
• src/styles.css holds global styles that apply across the whole application.
• src/app/ contains the root component, split into app.ts (the TypeScript class), app.html (its template), app.css (styles scoped to that component) and app.spec.ts (its unit test).
• public/ holds static assets served as-is.
• angular.json configures how the CLI builds, serves and tests the project.
• package.json lists dependencies and npm scripts; node_modules/ is where npm installed them.
• tsconfig.json configures the TypeScript compiler.

You do not need to understand every file yet. Knowing where the entry point, the root component and the configuration live is enough to get started.

Step 6: run the development server

From inside the project folder, start the app:

ng serve

The CLI compiles the application and starts a local development server. It also watches the source files and rebuilds whenever one changes. When the build finishes, you will see output similar to:

Application bundle generation complete.
Local: http://localhost:4200/

Open that address in your browser:

http://localhost:4200

The default starter page should appear. If you would rather not type the URL every time, add the --open flag and the CLI will launch your default browser for you:

ng serve --open

If port 4200 is already taken by another process, you can choose a different one with the --port option.

Step 7: make a change and watch it rebuild

To prove the whole loop works, edit the root component's template:

src/app/app.html

Replace everything in that file with a short piece of markup:

<h1>Hello Angular 22!</h1>
<p>
  My first Angular application is running successfully.
</p>

Save, then switch back to the browser. The page updates on its own. Because the development server watches your files and rebuilds on change, ordinary source edits never require stopping and restarting ng serve. Changes to configuration files such as angular.json are the exception and usually need a restart.

Displaying values from the component class

Static markup is only half the story. Next, extend the template so it also shows values coming from the component. The double curly braces are placeholders that Angular fills in from the class:

<div class="container">
<h1>{{ title }}</h1>
  <p>{{ message }}</p>
  <h1>Hello Angular 22!</h1>
  <p>
    My first Angular application is running successfully.
  </p>
</div>

For those placeholders to resolve, the component class in app.ts needs matching properties. The @Component decorator tells Angular that this class is a component, which tag it renders into (app-root, the element already present in index.html), and where its template and styles live:

import { Component } from '@angular/core';

@Component({
  selector: 'app-root',
  templateUrl: './app.html',
  styleUrl: './app.css'
})
export class App {
  title = 'My First Angular 22 App';
  message = 'Angular project is running successfully!';
}

With both files saved, the page shows the title and message from the class above the static content. Depending on the exact CLI version, the generated app.ts may look slightly different (newer templates sometimes use signals for the title), but a plain class property like this works the same way for learning purposes. If you want to experiment before installing anything, a StackBlitz version of this example runs entirely in the browser.

How the pieces connect at startup

With a running app, it helps to see the path from the browser to your template:

Browser
                   │
                   ▼
              index.html
                   │
                   ▼
                main.ts
                   │
                   ▼
              App Component
                   │
          ┌────────┴────────┐
          ▼                 ▼
       app.html          app.css
       (HTML)             (CSS)

The browser loads index.html. The bundled scripts run main.ts, the application's entry point, which bootstraps the root component. That component pairs its class with its HTML template and its styles, renders into the app-root element, and from then on Angular keeps the user interface in sync as the component's data changes. This picture is deliberately simplified, but it gives you a mental map to attach later topics to.

A minimal example of data binding

Here is the smallest useful version of that idea. The component class defines a single property:

import { Component } from '@angular/core';
@Component({
  selector: 'app-root',
  templateUrl: './app.html',
  styleUrl: './app.css'
})
export class App {
  title = 'My First Angular App';
}

and the template refers to it:

<h1>{{ title }}</h1>
<p>
  Welcome to my Angular 22 journey!
</p>

Two lines carry the whole concept. In the TypeScript class there is a property assignment:

title = 'My First Angular App';

and in the template there is an interpolation expression:

{{ title }}

Angular reads the value from the class and inserts it into the rendered HTML. This is interpolation, the simplest form of Angular's data binding. If you later change title in response to user input or data from a server, Angular updates the page for you. Property binding, event binding and two-way binding build on the same principle and deserve their own deep dive.

Why older tutorials look different

Search for Angular tutorials and you will quickly find projects with a different layout. An older guide typically shows files like these:

app.component.ts
app.component.html
app.component.css
app.module.ts

while a project generated with today's CLI contains:

app.ts
app.html
app.css

and often no app.module.ts at all. The framework has changed significantly over the years. Modern Angular uses standalone APIs by default: components declare their own dependencies directly, so new applications rarely need an NgModule to group them. The current CLI generates standalone applications and follows the newer, shorter naming conventions out of the box.

This does not make older code wrong. Plenty of production applications still use modules and the longer .component.ts names, and both styles are supported. But when you are learning, mixing the two approaches is a common source of confusion. If a tutorial tells you to edit app.module.ts and your project does not have one, you are looking at the older style, and you should look for a standalone equivalent instead of creating the file by hand.

Wrapping up

The Angular CLI turns project setup into a short, repeatable routine. Once you have done it once, the whole flow looks like this:

• Install a Node.js version that your Angular major supports, and verify node and npm.
• Install the CLI with npm install -g @angular/cli@22 and confirm it with ng version.
• Scaffold a project with ng new, accepting the standalone defaults for a first app.
• Get to know main.ts, index.html, the app.* files, angular.json and package.json.
• Run ng serve (optionally with --open) and rely on automatic rebuilds while you edit.
• Treat NgModule-based, .component.ts-style tutorials as the older approach and translate them to standalone APIs.

You do not need to understand every generated file on day one. What matters is that you have a working Angular 22 project and know where its main pieces live, which is the foundation for learning components, templates and data binding in depth.