NgModule Anatomy

## What an NgModule is An **NgModule** is a class marked with the `@NgModule` decorator from `@angular/core`. Its metadata tells Angular two things: how to **compile the templates** of the components it owns, and which **providers** to add to dependency injection. Before standalone components, every Angular app was assembled from NgModules. Today the Angular documentation recommends standalone components for all new code, and standalone is the default since v19 — but most production codebases still contain modules, so interviewers still ask what each field does. ```ts import { NgModule } from '@angular/core'; import { BrowserModule } from '@angular/platform-browser'; @NgModule({ declarations: [App, UserList, UserCard], imports: [BrowserModule, OrdersModule], exports: [UserCard], providers: [AuditLog], bootstrap: [App], }) export class AppModule {} ``` ## The five fields | Field | What goes in it | What it controls | |---|---|---| | `declarations` | Components, directives and pipes marked `standalone: false` | Which declarables **belong** to this module; each can belong to exactly one | | `imports` | Other NgModules, plus standalone components, directives and pipes | What this module's declared templates may **use** | | `exports` | Its own declarables, and anything it imports (including whole modules) | What **importing** modules' templates may use | | `providers` | Services and provider recipes | What is added to the **injector** for this module and its importers | | `bootstrap` | The root component(s), only on the root module | What `bootstrapModule` renders at startup | ### `declarations` A declarable must say `standalone: false` to be declared, because standalone is the default. Declaring the same class in two modules is a compile error, so a component shared by features lives in one module and is exported from it. ### `imports` Everything a declared template uses — another module's exported components, a pipe, a standalone directive — must reach it through `imports`. Importing a module gives you that module's **exports**, not its private declarations. ### `exports` Exports make things **visible** to importers. A module can re-export what it imports, which is how a "shared" module hands a bundle of building blocks to many feature modules. ### `providers` Providers listed here are registered with the injector that loads the module. For an eagerly imported module that is the application's root injector, so the services are app-wide singletons. For a lazily loaded module it is a separate child injector — which is why module providers and lazy loading interact badly (see `forRoot`). ### `bootstrap` Only the root module uses it. `platformBrowser().bootstrapModule(AppModule)` finds the elements in `index.html` that match the listed components' selectors and renders them. Components listed in `bootstrap` are treated as declared by that module. If the root module has neither `bootstrap` entries nor an `ngDoBootstrap` method, Angular throws `NG0403`. ## Two responsibilities, one decorator The fields fall into two groups that are easy to confuse: - **Template compilation** — `declarations`, `imports`, `exports`. These decide which selectors, attributes and pipe names a template can resolve. They have nothing to do with DI. - **Dependency injection** — `providers` (and the providers carried by imported modules). These decide what `inject()` can return. They have nothing to do with templates. Mixing the groups up produces classic mistakes: exporting a service (exports hold declarables and modules, not services), or expecting a component to become usable just because its service was provided. ## Why new code is standalone-first A standalone component lists its own template dependencies in its `imports` array. That removes the indirection of "which module declares me, and what does that module import?": - A component's dependencies are visible in its own file. - There is no shared module to keep in sync, and no risk of declaring a class twice. - Lazy loading works per component (`loadComponent`) rather than per module. Modules are not deprecated. They remain a supported way to group declarables and providers, and libraries still ship them. What changed is the default: new code starts standalone, and modules are what you read, maintain and migrate. ## Common mistakes - Putting a service in `exports` or a component in `providers`. - Declaring a standalone component instead of importing it. - Assuming `imports` gives access to a module's non-exported declarations. - Adding `bootstrap` to a feature module. - Expecting a module's `providers` to be private to that module — for an eagerly imported module they are registered in the root injector and visible app-wide. A quick way to self-check in an interview is to ask of each entry: *does this change what a template can resolve, or what `inject()` can return?* The answer tells you which field it belongs in.