Angular Migration

Shared rule (both variants)

Migrations are their own scoped task — never opportunistic ("while I'm in here"). Require characterization tests on the target before starting if none exist (consult characterization-tests). Run the verify commands after every component/slice, not once at the end.

Variant A — NgModule → Standalone

1. Order: leaf components first (no other component depends on them), then containers, then the module's routing config, then delete the NgModule last, once nothing imports it.
2. Codemod: use the Angular CLI schematic if the repo's Angular version ships one (ng generate @angular/core:standalone) — run it per-target, not repo-wide, so failures are isolated to one component.
3. Manual steps: verify imports: array on each converted component lists only what it actually uses (schematics sometimes over-include); check barrel/index re-exports still resolve; update any NgModule.declarations reference that pointed at the converted component.
4. Verify: build + the component's tests green + the app boots (smoke check on a route that renders this component) before moving to the next one.

Variant B — Classic NgRx store → Signals store

1. Order: migrate one feature slice's state at a time (actions → reducer → selectors → effects, in that order within the slice); never half-migrate a slice (some selectors on signals, others still classic) — that's a harder-to-debug intermediate state than either pure form.
2. Codemod: no reliable automated codemod for this direction as of current Angular/NgRx tooling — treat as manual, and say so; don't imply automation that doesn't exist.
3. Manual steps: replace Store.select(selector) + async pipe with the signals-store equivalent read; convert effects to the signals-store pattern one at a time; keep the old reducer/selector file until the slice's tests pass against the new implementation, then delete it (not before — keeping both lets you diff behavior if something looks off).
4. Verify: full test suite for the slice green, plus a manual equivalence spot-check (consult /equiv-plan if the slice has complex derived-state logic) before deleting the old files.

Anti-patterns

• Never run a codemod repo-wide in one shot — per-component/per-slice, so a failure doesn't block everything else and each step stays revertible.
• Never leave a component or slice half-migrated across a session boundary without recording it in session-state — "half-standalone" is an easy state to lose track of.
• Never claim a codemod exists for classic→signals when none does; the gap itself is useful information to the user planning the migration.