Navigating an Angular Workspace: Bootstrap, Routes, Providers, Build, and Features

Welcome back. You now have a strict Angular 17 workspace and a small standalone PortfolioStatusComponent rendering inside the root application shell. The next useful skill is not writing more code yet, but becoming fast at orienting yourself in an Angular repository.

In a GCB-WMP repository, you will regularly need to answer questions such as: “Where does the app start?”, “Which file owns this URL?”, “Where was this service registered?”, and “What configuration controls the build?” This lesson gives you a repeatable tracing method for those questions.

By the end, you will be able to locate the application bootstrap, route definitions, application-wide dependency providers, build configuration, and feature code in your local gcb-wmp-lab workspace.

---

Build the workspace map before reading individual files

Angular has two related structures:

1. The workspace root contains tooling, dependency, and build configuration.
2. The application source tree contains the code delivered to the browser.

Start with this high-level map. Your exact files may differ slightly across Angular CLI versions or a company repository, but the responsibilities remain consistent.

Location	Main responsibility	Question it answers
package.json	npm scripts and declared dependencies	How do I serve or build this project? Which packages does it use?
angular.json	Angular CLI build and serve targets	What gets built, served, copied, optimized, or output?
tsconfig.json	Base TypeScript compiler rules	Which TypeScript safety rules apply?
src/index.html	HTML document sent to the browser	Where does the browser receive the root host element?
src/main.ts	Angular application bootstrap	Which root component starts Angular?
src/app/app.config.ts	Application-wide providers	Which framework and application services are available globally?
src/app/app.routes.ts	Route definitions	Which URL maps to which feature or screen?
src/app/app.component.ts	Root component and application shell	What surrounds page content at the top level?
src/app/features/	Feature-specific UI and logic	Where does dashboard, accounts, transfers, or auth code live?
public/	Static assets copied without application compilation	Which files should be served as-is?

Read the following official overview now. It is useful as a stable reference when you later inspect a repository whose folder naming conventions differ from your lab.

A practical distinction matters here:

• index.html is the browser document entry point. It contains the host element, normally <app-root>.
• main.ts is the Angular runtime entry point. It starts Angular and tells it what should render into that host element.

The CLI adds compiled JavaScript and CSS to index.html during the build. You generally do not add script tags for Angular application files by hand.

---

Trace the bootstrap path

Open these files in order:

1. src/index.html
2. src/main.ts
3. src/app/app.config.ts
4. src/app/app.component.ts

In a standalone Angular 17 application, main.ts will look broadly like this:

import { bootstrapApplication } from '@angular/platform-browser';

import { AppComponent } from './app/app.component';
import { appConfig } from './app/app.config';

bootstrapApplication(AppComponent, appConfig)
  .catch((error) => console.error(error));

The first argument, AppComponent, identifies the standalone root component. The second argument, appConfig, contains application-level configuration, especially dependency providers.

The key point is that the root component is not merely “the first component file.” It is the component Angular creates at application startup. Its selector—normally app-root—matches the element in src/index.html.

Your current lab’s root component directly renders PortfolioStatusComponent. That was intentional in the previous lesson. In a routed banking application, the root component usually becomes an application shell: it might contain the main landmark, a top navigation component, persistent alerts, and a router outlet where page components render.

Read the official API description before continuing. It confirms two important constraints: bootstrapApplication starts the application, and its root must be standalone.

A useful code-reading habit is to follow imported symbols rather than guessing from a file name:

• In main.ts, follow AppComponent to app.component.ts.
• Follow appConfig to app.config.ts.
• In app.config.ts, follow routes to app.routes.ts.

That technique works even when an enterprise codebase uses names such as core.config.ts, platform.providers.ts, or banking.routes.ts.

---

Locate route configuration and the page-rendering boundary

With routing enabled, a generated standalone Angular application commonly has src/app/app.routes.ts:

import { Routes } from '@angular/router';

export const routes: Routes = [];

An empty array is still a valid route configuration. It simply means the project has not yet declared any URL-based screens.

The router is activated through an application provider, commonly in src/app/app.config.ts:

import { ApplicationConfig } from '@angular/core';
import { provideRouter } from '@angular/router';

import { routes } from './app.routes';

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes)
  ]
};

This establishes two distinct responsibilities:

• app.routes.ts declares route rules.
• app.config.ts registers Angular Router as an application capability and supplies those route rules.

For routes to become visible, some component must use Angular’s RouterOutlet directive in its template. In a typical root shell, that looks like this:

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

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [RouterOutlet],
  template: `
    <header>
      <h1>GCB-WMP Frontend Lab</h1>
    </header>

    <main>
      <router-outlet />
    </main>
  `
})
export class AppComponent {}

Notice the two separate imports concepts again:

• The TypeScript import at the top allows RouterOutlet to be referenced by the TypeScript file.
• The decorator’s imports array makes <router-outlet /> available to the component template.

Your current app.component.ts may not contain RouterOutlet, because it was simplified to render the portfolio status card directly. That is not an error. It means routing is configured structurally but no route content has a visual outlet yet. You will make the root component into a routed shell when you begin building dashboard, accounts, transfers, and auth pages.

When reading a future GCB-WMP route file, inspect each route in this order:

1. Its path, which identifies the URL segment.
2. Its component or loadComponent, which identifies the screen code.
3. Its children, if the feature has nested pages.
4. Its canActivate or related properties, which indicate route protection.
5. Its providers, if the route has feature-scoped services.

You do not need to implement guards or lazy-loaded routes yet. For now, the important skill is recognizing where the URL configuration lives and how to trace from a route to the component it renders.

---

Understand providers as Angular’s dependency map

A provider tells Angular how to obtain a dependency when a component, service, guard, or interceptor asks for one.

The app.config.ts file is the most important place to look for application-wide providers. It is where you will later find registrations such as:

providers: [
  provideRouter(routes)
]

Later in the course, this same array may contain registrations for HTTP communication, interceptors, animations, or other platform-wide behavior. The critical reading question is: what service or capability becomes available because of this provider?

The injector is Angular’s dependency-resolution mechanism. It receives a request for a dependency and supplies an instance according to registered provider rules.

There are several provider locations you will encounter:

Provider location	Typical scope	What to look for
app.config.ts	Whole application	providers: [...], such as provideRouter(...)
@Injectable({ providedIn: 'root' })	Whole application	A service that Angular can create from its own metadata
Route configuration	That route and its child routes	A feature-specific providers array
Component decorator	That component’s subtree	providers: [...]; use deliberately because it creates a scoped instance

For example, a later AccountService may be declared like this:

@Injectable({
  providedIn: 'root'
})
export class AccountService {}

In that case, you may not find AccountService listed in app.config.ts. Its provider is declared in the service metadata itself. This is why a complete repository search should include both providers: and providedIn:.

Do not confuse a component’s imports array with an application config’s providers array:

• Component imports make template features available.
• Providers make injectable capabilities available.

That distinction will prevent many early Angular errors, particularly when moving from React’s import-driven component model.

---

Find build, dependency, and TypeScript configuration

Return to the workspace root—outside src/. Three files are essential for day-to-day orientation.

package.json: commands and dependencies

Open package.json and inspect:

• scripts
• dependencies
• devDependencies

The scripts turn short npm commands into project actions. In your lab, you will commonly see equivalents of:

{
  "scripts": {
    "start": "ng serve",
    "build": "ng build"
  }
}

Therefore:

npm start

runs the development server, while:

npm run build

creates a production-oriented application build.

dependencies contains packages required by the application at runtime, such as Angular framework packages and RxJS. devDependencies contains build tooling, the Angular CLI, TypeScript, and related development-time tools. Use package-lock.json as the exact record of resolved package versions; commit it with package.json, but do not edit it casually.

angular.json: CLI targets and build behavior

Open angular.json. Its structure varies somewhat with CLI versions, but look under:

projects
  <application name>
    architect or targets
      build
      serve

The build configuration commonly controls:

• the builder used to compile the application;
• the source entry file, often src/main.ts;
• the HTML document, often src/index.html;
• global styles, commonly src/styles.scss;
• static files copied from public/;
• output directory and production settings;
• bundle budgets that warn or fail when bundles become too large.

The serve target runs a development server based on an associated build target. Treat angular.json as build-system configuration, not an ordinary place to add application logic.

For a performance-sensitive banking SPA, the configuration deserves attention because a large initial JavaScript bundle delays useful UI. However, do not change builder, optimization, or budget settings merely because they are present. First identify their purpose, reproduce the existing build, and understand the team convention.

tsconfig.json: compiler baseline

The workspace-level tsconfig.json is the base TypeScript configuration. Its child configuration files can add or override rules for specific build contexts.

From the previous lesson, you already verified:

{
  "compilerOptions": {
    "strict": true
  }
}

In an unfamiliar repository, check this early. Strictness directly affects what kinds of DTO mismatches, nullable values, and template assumptions TypeScript and Angular will reject.

---

Perform a deliberate reconnaissance of your lab

Spend about 10–15 minutes tracing the actual files instead of only reading about them. Keep ng serve running if convenient, but no code change is required for this activity.

First, from the workspace root, list the application tree. On macOS, Linux, or Git Bash:

find src -maxdepth 5 -type f | sort

In PowerShell:

Get-ChildItem src -Recurse -File | Select-Object FullName

Then use a repository search to find the major Angular entry points:

rg -n "bootstrapApplication|provideRouter|RouterOutlet|providers|providedIn" src

If rg (ripgrep) is unavailable, use your editor’s global search with the same terms.

Create a local note such as docs/workspace-map.md and record these facts from your project:

# GCB-WMP Lab Workspace Map

- Browser document: src/index.html
- Angular bootstrap: src/main.ts
- Root component: src/app/app.component.ts
- Global providers: src/app/app.config.ts
- Routes: src/app/app.routes.ts
- Build and serve configuration: angular.json
- npm scripts and packages: package.json
- TypeScript baseline: tsconfig.json
- Current dashboard feature:
  src/app/features/dashboard/portfolio-status/portfolio-status.component.ts

The final path reflects the component you generated in the previous lesson:

src/app/features/dashboard/portfolio-status/
  portfolio-status.component.ts

Because you generated it with --inline-template --inline-style, its HTML and SCSS live inside the .component.ts file. In a company codebase, a component often uses separate .html and .scss files instead. Both forms are legitimate; follow the local project convention rather than assuming every Angular component must have the same number of files.

For future features, a maintainable banking-oriented layout will commonly group code by business area:

src/app/
  core/
  shared/
  features/
    auth/
    dashboard/
    accounts/
    transfers/
    notifications/

At this stage, treat that as a navigation convention, not a folder structure you must create immediately. The codebase itself is the authority.

---

Completion checkpoint

You can now orient yourself in an Angular workspace when you can state, without searching randomly:

• src/index.html is the browser document, while src/main.ts starts Angular.
• bootstrapApplication(AppComponent, appConfig) identifies the root standalone component and supplies application-level configuration.
• app.config.ts is the first place to inspect global providers.
• app.routes.ts declares URL-to-screen rules, while RouterOutlet provides the template location where routed content renders.
• angular.json controls Angular CLI build and serve behavior.
• package.json provides npm scripts and package declarations.
• tsconfig.json establishes TypeScript compiler rules, including strictness.
• src/app/features/ is the natural place to trace business functionality such as dashboard, accounts, transfers, and authentication.

---

You now have a practical map of the Angular workspace rather than a collection of unfamiliar files. Next, you will translate your existing React knowledge into Angular terms—components, inputs, local state, lifecycle, dependency injection, and template rendering—while being careful about the differences that matter in a standalone Angular application.