Angular Project Structure

Analogy categoryAnalogies

When the Angular CLI scaffolds a new project, it produces a predictable folder and file layout that every Angular developer learns to recognize. Understanding this structure early makes it much easier to navigate unfamiliar Angular codebases, because most Angular projects — regardless of team or company — organize themselves around the same core conventions: a src/app folder holding application code, configuration files at the root, and a clear separation between source, tests, and build output.

🏏

Cricket analogy: Just as every international cricket ground follows the same 22-yard pitch and boundary conventions so any player can walk onto a new stadium and know where the crease is, a freshly scaffolded Angular project follows the same folder conventions so any developer can walk into a new codebase and find src/app immediately.

The Root-Level Files

At the project root you'll find angular.json (the workspace configuration describing build targets, assets, and styles), package.json (npm dependencies and scripts), tsconfig.json and its variants (tsconfig.app.json, tsconfig.spec.json) controlling TypeScript compilation for the app versus tests, and often eslint or prettier configuration files. angular.json in particular is worth understanding early: it defines named 'architect' targets like build, serve, and test, each mapped to a builder (historically webpack-based, now commonly the esbuild-based application builder) with its own options.

🏏

Cricket analogy: angular.json is like the ICC's official match regulations document specifying pitch dimensions, over limits, and DRS rules for each format (Test, ODI, T20), while package.json is the squad list of players (dependencies) selected for the tour.

Inside src/app

The src/app folder is where application logic lives. A freshly generated standalone project contains app.component.ts (the root component), app.config.ts (application-wide providers such as the router and HTTP client, supplied to bootstrapApplication), and, if routing was selected, app.routes.ts defining the route table. As an application grows, teams typically organize src/app either by feature (a folder per business domain, e.g. orders/, users/) or by type (a folder per artifact kind, e.g. components/, services/), with feature-based organization strongly preferred for anything beyond a small demo, since it keeps related files physically close together.

🏏

Cricket analogy: Organizing src/app by feature (orders/, users/) is like a franchise splitting its backroom staff into a batting unit and a bowling unit rather than grouping everyone by job title, keeping each unit's specialists physically together in the same dressing room.

typescript

src/
  app/
    app.component.ts
    app.component.html
    app.component.scss
    app.config.ts        // providers: router, http client, etc.
    app.routes.ts        // route table
    orders/
      order-list.component.ts
      order-detail.component.ts
      order.service.ts
    users/
      user-profile.component.ts
      user.service.ts
  assets/
    logo.svg
  index.html
  main.ts                // bootstrapApplication(AppComponent, appConfig)
  styles.scss             // global styles

Angular's official style guide historically recommended a strict 'core/shared/feature' module split under NgModules. With standalone components, that ceremony is largely unnecessary — feature folders with self-contained standalone components and their own routes are now the more common, lighter-weight pattern.

A frequent mistake in growing codebases is dumping unrelated services into a single flat services/ folder. This works fine early on but becomes a bottleneck for code review and refactors; co-locating a service with the feature that primarily owns it (and only promoting it to a shared/core location once genuinely reused) scales better.

angular.json centralizes build, serve, and test configuration via named 'architect' targets and builders.
main.ts bootstraps the application by calling bootstrapApplication with the root component and app.config.ts providers.
app.config.ts holds application-wide providers such as the router and HttpClient in a standalone setup.
app.routes.ts defines the route table when routing is enabled.
Feature-based folder organization (grouping by business domain) scales better than type-based organization as an app grows.
tsconfig.app.json and tsconfig.spec.json separate TypeScript compilation concerns for application code versus tests.

Practice what you learned

1. Which file centralizes an Angular workspace's build, serve, and test configuration?

2. In a standalone-component Angular project, what does main.ts typically call to start the app?

3. What is the role of app.config.ts in a standalone project?

4. Which folder organization strategy is generally preferred for medium-to-large Angular applications?

5. What distinguishes tsconfig.app.json from tsconfig.spec.json?

Was this page helpful?

Setting Up an Angular Project

The Angular CLI

Related Study Notes in Web Development

Browse all study notes

Web Development

WebSockets Study Notes

Web Development · 30 topics

Web Development

WebAssembly Study Notes

WebAssembly · 30 topics

Web Development

gRPC Study Notes

Protocol Buffers · 30 topics

Web Development

Spring Boot Study Notes

Java · 30 topics

Web Development

Flask Study Notes

Python · 30 topics

Web Development

Django Study Notes

Python · 30 topics

Topics covered

#TypeScript#AngularStudyNotes#WebDevelopment#AngularProjectStructure#Angular#Project#Structure#Root#StudyNotes#SkillVeris

Angular Project Structure