The CLI and Project Anatomy

The plain-language idea

ng new my-app isn't a folder-and-README generator. It scaffolds a project that already builds, serves, and bootstraps a working (if empty) app, using the same builder the Angular team ships and maintains: @angular/build. Under the hood that's esbuild doing the actual bundling for speed, and a Vite-powered dev server doing fast rebuilds and hot module replacement while you work. If you've seen older Angular tutorials referencing a webpack-based builder (@angular-devkit/build-angular) with long cold-start times, that's the previous generation — new projects default to the esbuild/Vite pipeline now, and it's dramatically faster to both build and serve.

What actually matters here isn't the build tool trivia — it's that the CLI's output is the framework's opinion made concrete. Every generated file corresponds to one of the framework decisions from the previous lesson: where bootstrapping happens, where providers get registered, where routes live. Once you can read a generated project, you can read any Angular project.

See it in a real thing: what ng new actually writes

A freshly generated app's src/ directory looks like this:

src/
  main.ts                 # entry point — calls bootstrapApplication
  index.html               # the single HTML shell the app mounts into
  styles.css                # global styles
  app/
    app.component.ts        # root component
    app.component.html      # (or inline template, CLI asks you which)
    app.config.ts           # ApplicationConfig — where providers are registered
    app.routes.ts           # Routes array — where the router is configured
angular.json                # builder config: which builder, build targets, file replacements
package.json                # dependencies + npm scripts (ng build, ng serve, ng test)

The three files that actually matter for understanding how the app starts are main.ts, app.config.ts, and app.routes.ts — and you already saw how they connect in the previous lesson. main.ts is deliberately tiny: its only job is calling bootstrapApplication, passing the root component and the appConfig object. Everything about how the app is configured — router, HTTP client, any other providers — lives in app.config.ts, not scattered across main.ts.

angular.json is the one file most Angular developers never open, but it's not boilerplate — it's where the builder itself is configured:

{
  "projects": {
    "my-app": {
      "architect": {
        "build": {
          "builder": "@angular/build:application",
          "options": {
            "outputPath": "dist/my-app",
            "index": "src/index.html",
            "browser": "src/main.ts"
          }
        },
        "serve": {
          "builder": "@angular/build:dev-server"
        }
      }
    }
  }
}

That "builder": "@angular/build:application" line is the esbuild-based, current-generation builder. If you ever inherit a project where that value instead points at @angular-devkit/build-angular:browser, you're looking at the older webpack pipeline — the component code you write doesn't change, but build times and dev-server behavior will.

What people usually miss

Watch out

• angular.json isn't optional boilerplate — it's live configuration. Build targets, asset paths, budget limits (bundle size warnings/errors), and environment file replacements all live here. Ignoring it means missing why a production build behaves differently from ng serve.
• ng generate schematics are just file templates, not magic. You can always hand-write the same component/service/directive yourself — the CLI just saves you from retyping the decorator boilerplate and gets the naming conventions right.
• The esbuild/Vite builder swap is a build-tool change, not an API change. Your components, services, and templates are written exactly the same way regardless of which builder is configured — this is purely about how fast ng build and ng serve are, not what you're allowed to write.

The genealogy: this is where the mental model becomes files

The previous lesson described Angular as a framework whose pieces are "designed together" — this lesson is that claim made literal: app.config.ts's providers array, app.routes.ts's route table, and main.ts's single bootstrap call are the actual files where that design shows up. The next lesson digs into what a standalone component itself looks like once it's one of the things being bootstrapped.