A module-based Angular app wants its first standalone feature, a lazily loaded reports area; how do you add it without converting the rest of the app?

## The scenario A mature Angular app is entirely module-based: `AppModule` with `bootstrapModule`, an `AppRoutingModule` using `RouterModule.forRoot`, feature modules, and a `SharedModule` of common components. The team wants to build the next feature — a lazily loaded **reports** area — as standalone code, without converting anything else yet. This works because the router and the compiler do not care whether the surrounding app is module-based. The steps below keep the change inside the new feature. ## Step 1: build the feature as standalone components Generate the feature's components as standalone (the default since v19). Each lists its own template dependencies: ```ts @Component({ selector: 'app-reports-page', imports: [SharedModule, ReportChart], template: `<app-page-header title="Reports" /><app-report-chart [data]="data()" />`, }) export class ReportsPage { readonly data = inject(ReportsStore).summary; } ``` - **Old building blocks** come in by importing their module — here `SharedModule`, for `<app-page-header>`. The page sees only what `SharedModule` exports. - **New building blocks** such as `ReportChart` are standalone and imported directly. ## Step 2: add a lazy route in the existing routing module The existing `RouterModule.forRoot(routes)` accepts routes that load standalone code: ```ts const routes: Routes = [ // ...existing module-based routes using loadChildren... { path: 'reports', loadChildren: () => import('./reports/reports.routes').then((m) => m.REPORTS_ROUTES), }, ]; ``` `REPORTS_ROUTES` is a plain `Routes` array whose entries use `component` or `loadComponent`. No `ReportsModule` and no `RouterModule.forChild` are needed. ## Step 3: put feature services where they belong - A service used only in this feature can be listed in the parent route's `providers` array, which creates an environment injector for the reports routes. `providers: [ReportsStore]` on the `reports` route gives the feature one shared store that disappears from other areas. - A service used app-wide should be `@Injectable({ providedIn: 'root' })`. - A legacy library that only offers `SomeModule.forRoot()` can be bridged with `importProvidersFrom(...)` on that same route. ## Step 4: watch for the provider trap If `SharedModule` has its own `providers`, importing it into `ReportsPage` is not free. When the router creates a standalone component, Angular walks the component's import graph and puts any NgModule providers it finds into a **standalone injector** created for that component. The reports page would then get **its own copies** of `SharedModule`'s services — the same duplicate-singleton bug lazy NgModules have always had. The fix is to move those services to `providedIn: 'root'` (or a core module imported once) so that `SharedModule` carries declarables only. It is often the first piece of the migration worth doing anyway. ## What to leave alone for now | Keep as is | Why | |---|---| | `bootstrapModule(AppModule)` | The bootstrap style does not limit standalone features | | `RouterModule.forRoot` in `AppRoutingModule` | It happily loads standalone routes | | Other feature modules | They can keep working; convert them later, leaf components first | | `SharedModule` (minus its providers) | The new feature imports it until its pieces are standalone | ## How to verify the adoption - The reports chunk loads only when the route is visited — check the build output lists a separate lazy chunk for it. - The AOT build catches missing template imports as `NG8001` errors, so scope mistakes show up at build time. - Inject a shared service in both an old page and the reports page and confirm it is the same instance. ## Testing the new feature Standalone components are also simpler to test inside the old app. A `TestBed` configuration for `ReportsPage` imports the component itself — its template dependencies come along through its `imports` — instead of re-creating a testing module that declares the component and imports everything its template might need. Services such as `ReportsStore` are supplied through the test's `providers`, and a fake can replace the real one there. ## Why this is the recommended first step It gives the team hands-on standalone experience on new code, proves that the build, tests and lint rules handle standalone, and exposes provider problems in shared modules — all without touching the stable parts of the app. Subsequent migrations follow the same pattern in the other direction: convert leaf components and import them into their old modules.