docs: add eager to lazy route migration

adev/src/app/sub-navigation-data.ts

@@ -1472,6 +1472,11 @@ const REFERENCE_SUB_NAVIGATION_DATA: NavigationItem[] = [
         path: 'reference/migrations/inject-function',
         contentPath: 'reference/migrations/inject-function',
       },
+      {
+        label: 'Eager to lazy routes',
+        path: 'reference/migrations/inject-function',
+        contentPath: 'reference/migrations/inject-function',
+      },
     ],
   },
   {

adev/src/content/reference/migrations/inject-function.md

@@ -13,18 +13,22 @@ ng generate @angular/core:inject
 </docs-code>
 
 #### Before
+
 <docs-code language="typescript">
 import { Component, Inject, Optional } from '@angular/core';
 import { MyService } from './service';
 import { DI_TOKEN } from './token';
 
 @Component()
 export class MyComp {
-  constructor(private service: MyService, @Inject(TOKEN) @Optional() readonly token: string) {}
+  constructor(
+    private service: MyService,
+    @Inject(TOKEN) @Optional() readonly token: string) {}
 }
 </docs-code>
 
 #### After
+
 <docs-code language="typescript">
 import { Component, inject } from '@angular/core';
 import { MyService } from './service';
@@ -38,26 +42,31 @@ export class MyComp {
 </docs-code>
 
 ## Migration options
+
 The migration includes several options to customize its output.
 
 ### `path`
+
 Determines which sub-path in your project should be migrated. Pass in `.` or leave it blank to
 migrate the entire directory.
 
 ### `migrateAbstractClasses`
+
 Angular doesn't validate that parameters of abstract classes are injectable. This means that the
 migration can't reliably migrate them to `inject` without risking breakages which is why they're
 disabled by default. Enable this option if you want abstract classes to be migrated, but note
 that you may have to **fix some breakages manually**.
 
 ### `backwardsCompatibleConstructors`
+
 By default the migration tries to clean up the code as much as it can, which includes deleting
 parameters from the constructor, or even the entire constructor if it doesn't include any code.
 In some cases this can lead to compilation errors when classes with Angular decorators inherit from
 other classes with Angular decorators. If you enable this option, the migration will generate an
 additional constructor signature to keep it backwards compatible, at the expense of more code.
 
 #### Before
+
 <docs-code language="typescript">
 import { Component } from '@angular/core';
 import { MyService } from './service';
@@ -69,6 +78,7 @@ export class MyComp {
 </docs-code>
 
 #### After
+
 <docs-code language="typescript">
 import { Component } from '@angular/core';
 import { MyService } from './service';
@@ -85,6 +95,7 @@ export class MyComp {
 </docs-code>
 
 ### `nonNullableOptional`
+
 If injection fails for a parameter with the `@Optional` decorator, Angular returns `null` which
 means that the real type of any `@Optional` parameter will be `| null`. However, because decorators
 cannot influence their types, there is a lot of existing code whose type is incorrect. The type is
@@ -96,6 +107,7 @@ at the expense of potentially hiding type errors.
 because the code that depends on them likely already accounts for their nullability.
 
 #### Before
+
 <docs-code language="typescript">
 import { Component, Inject, Optional } from '@angular/core';
 import { TOKEN_ONE, TOKEN_TWO } from './token';
@@ -109,6 +121,7 @@ export class MyComp {
 </docs-code>
 
 #### After
+
 <docs-code language="typescript">
 import { Component, inject } from '@angular/core';
 import { TOKEN_ONE, TOKEN_TWO } from './token';

adev/src/content/reference/migrations/overview.md

@@ -7,9 +7,12 @@ Learn about how you can migrate your existing angular project to the latest feat
     Standalone components provide a simplified way to build Angular applications. Standalone components specify their dependencies directly instead of getting them through NgModules.
   </docs-card>
   <docs-card title="Control Flow Syntax" link="Migrate now" href="reference/migrations/control-flow">
-    Control Flow Syntax is available with Angular 17 release and allows you to use more ergonomic syntax which is close to javascript, better type checking and lazy load part of the component. It replaces the need to imports CommonModule to use functionalities like `*ngFor`, `*ngIf`.
+    Built-in Control Flow Syntax allows you to use more ergonomic syntax which is close to JavaScript and has better type checking. It replaces the need to import `CommonModule` to use functionality like `*ngFor`, `*ngIf` and `*ngSwitch`.
   </docs-card>
   <docs-card title="inject() Function" link="Migrate now" href="reference/migrations/inject-function">
     Angular's `inject` function offers more accurate types and better compatibility with standard decorators, compared to constructor-based injection.
   </docs-card>
+  <docs-card title="Lazy routes" link="Migrate now" href="reference/migrations/route-lazy-loading">
+    Convert eagerly loaded component routes to lazy loaded ones. This allows to split production bundles into smaller chunks, to load less JavaScript at initial page load.
+  </docs-card>
 </docs-card-container>

adev/src/content/reference/migrations/route-lazy-loading.md

@@ -0,0 +1,75 @@
+# Migration from eager to lazy routes
+
+This schematic helps developers to convert eagerly loaded component routes to lazy loaded routes. This allows to split the production bundle into smaller chunks, to avoid big JS bundle that includes all routes, which negatively affects initial page load of an application.
+
+Run the schematic using the following command:
+
+<docs-code language="shell">
+
+ng generate @angular/core:route-lazy-loading
+
+</docs-code>
+
+## `path` config option
+
+By default, migration will go over the entire application. If you want to apply this migration to a subset of the files, you can pass the path argument as shown below:
+
+<docs-code language="shell">
+
+ng generate @angular/core:route-lazy-loading --path src/app/sub-component
+
+</docs-code>
+
+The value of the path parameter is a relative path within the project.
+
+### How does it work?
+
+The schematic will attempt to find all the places where the application routes as defined:
+
+- `RouterModule.forRoot` and `RouterModule.forChild`
+- `Router.resetConfig`
+- `provideRouter`
+- `provideRoutes`
+- variables of type `Routes` or `Route[]` (e.g. `const routes: Routes = [{...}]`)
+
+The migration will check all the components in the routes, check if they are standalone and eagerly loaded, and if so, it will convert them to lazy loaded routes.
+
+#### Before
+
+<docs-code language="typescript">
+// app.module.ts
+import { HomeComponent } from './home/home.component';
+
+@NgModule({
+  imports: [
+    RouterModule.forRoot([
+      {
+        path: 'home',
+        // HomeComponent is standalone and eagerly loaded
+        component: HomeComponent,
+      },
+    ]),
+  ],
+})
+export class AppModule {}
+</docs-code>
+
+#### After
+
+<docs-code language="typescript">
+// app.module.ts
+@NgModule({
+  imports: [
+    RouterModule.forRoot([
+      {
+        path: 'home',
+        // ↓ HomeComponent is now lazy loaded
+        loadComponent: () => import('./home/home.component').then(m => m.HomeComponent),
+      },
+    ]),
+  ],
+})
+export class AppModule {}
+</docs-code>
+
+This migration will also collect information about all the components declared in NgModules and output the list of routes that use them (including corresponding location of the file). Consider making those components standalone and run this migration again. You can use an existing migration (see https://angular.dev/reference/migrations/standalone) to convert those components to standalone.