In Angular, why do modules such as RouterModule expose forRoot() and forChild(), and what goes wrong if a lazy-loaded module imports forRoot()?

## The problem the convention solves An NgModule can carry **providers**. When a module is imported eagerly, its providers land in the application's root injector and every consumer shares one instance. But a **lazily loaded** NgModule is given its **own child injector**. If that lazy module imports a module with providers, those providers are registered again in the child injector, and code inside the lazy feature gets a **second instance** of what was meant to be a singleton. Some modules also need **configuration** — a route table, an API key, a feature flag — that should be given once for the whole app, while feature areas add only their part. The `forRoot` / `forChild` pair is the convention that handles both problems. ## How the pattern works Both are **static methods** on the module class that return a **`ModuleWithProviders<T>`** — an object with the module (`ngModule`) and a `providers` list: ```ts interface ModuleWithProviders<T> { ngModule: Type<T>; providers?: Array<Provider | EnvironmentProviders>; } ``` - **`forRoot(config)`** returns the module **plus** its singleton services and the root configuration. It is imported **once**, by the root module (or, in a standalone app, wrapped in `importProvidersFrom` in the application config). - **`forChild(config)`** returns the module with **only** the feature-level configuration — no singleton services. Feature modules, including lazy ones, import this. - The module class itself usually has **no** `providers` in its `@NgModule` metadata, so importing the bare module (for its components and directives) never duplicates services. "forRoot" and "forChild" are names chosen by convention; Angular gives the method names no special meaning. ## The canonical example: `RouterModule` | | `RouterModule.forRoot(routes, options)` | `RouterModule.forChild(routes)` | |---|---|---| | Returns | `ModuleWithProviders<RouterModule>` | `ModuleWithProviders<RouterModule>` | | Registers the `Router` and its services | Yes | No | | Registers the route table | Yes | Yes — adds this feature's routes | | Accepts global options | Yes | No | | Imported by | The root module, once | Every feature module with routes | `RouterModule` protects itself: in development mode, if `forRoot` is used in an injector below one that already has a `Router`, it throws **`NG04007`**: "The Router was provided more than once. This can happen if 'forRoot' is used outside of the root injector. Lazy loaded modules should use RouterModule.forChild() instead." In a standalone app the router is configured with `provideRouter(routes)` instead, and lazy routes use `loadChildren` returning a `Routes` array, so neither method is needed there. ## What goes wrong without it Typical bugs the pattern prevents: - **Duplicate singletons.** A lazy feature imports `AuthModule`, which lists `AuthService` in its own `providers`. The feature gets a fresh `AuthService` with no logged-in user, while the rest of the app shows the user as signed in. - **Duplicate global setup.** A second router, a second store, a second interceptor chain — often with confusing symptoms rather than a clear error. - **Configuration drift.** Two feature modules each passing their own "global" config, with the last one loaded silently changing behaviour. ## Writing your own ```ts @NgModule({ declarations: [Toast], exports: [Toast] }) export class ToastModule { static forRoot(config: ToastConfig): ModuleWithProviders<ToastModule> { return { ngModule: ToastModule, providers: [ToastService, { provide: TOAST_CONFIG, useValue: config }], }; } } ``` Guidelines: 1. Keep singleton services **out** of the `@NgModule` `providers`; put them only in `forRoot`. 2. Provide `forChild` only if features genuinely add configuration. 3. Consider a guard like the router's for services that must never be duplicated. ## The modern alternative Services decorated with `@Injectable({ providedIn: 'root' })` are registered in the root injector regardless of which module imports what, which removed most of the need for `forRoot` in application code. New libraries expose `provideX()` functions returning `EnvironmentProviders` rather than `forRoot`. You still meet `forRoot`/`forChild` in older libraries and module-based apps, which is why interviewers ask about them. ## Guarding a core module against double import Module-based apps often pair `forRoot` with a **core module** that holds app-wide singletons and must be imported exactly once. The usual guard mirrors the router's check — the module's constructor looks for an existing instance in a *parent* injector: ```ts @NgModule({ providers: [SessionStore] }) export class CoreModule { constructor() { const parent = inject(CoreModule, { optional: true, skipSelf: true }); if (parent) { throw new Error('CoreModule is already loaded; import it in AppModule only.'); } } } ``` The check turns a silent duplicate-singleton bug into a loud startup error the first time someone imports the module from a lazy feature.