Angular Major Version Upgrade

Edit the version numbers below to match your target before running.

Upgrade every Angular app from its current major version to Angular 18.

For each repository:
1. Update `package.json` Angular dependencies (`@angular/core`, `@angular/cli`,
   `@angular/common`, `@angular/router`, etc.) to ^18.2.0.
2. Apply the equivalent of `ng update @angular/core@18 @angular/cli@18`
   directly: update the Angular CLI/Material/CDK config in `angular.json`, the
   compiler options in `tsconfig.json`, and `polyfills.ts` per Angular 18's
   migration schematics.
3. Replace deprecated APIs flagged in the Angular 18 release notes:
   - Migrate `@ViewChild({ static: false })` defaults
   - Replace `HttpClientModule` imports with `provideHttpClient` where Standalone is adopted
   - Update RxJS operator imports to RxJS 7.8
4. Convert eligible components to standalone (`standalone: true`) and update
   bootstrap to `bootstrapApplication`.
5. Update CI Node version in `.github/workflows/*.yml` to Node 20.x to match
   Angular 18's runtime floor.

The Problem

Angular's major version cadence (every six months) means most organizations are perpetually one or two majors behind. Each version introduces deprecations, schematic migrations, and peer-dependency requirements (Node version floors, TypeScript version bumps, RxJS majors) that compound across the dependency graph. `ng update` works on a single repo at a time, and only when the working tree is clean and the previous major's deprecations have already been resolved.

At organizational scale, that means dozens of frontends each stuck at a different version, with their own pinned RxJS, their own legacy `@ViewChild` defaults, their own `HttpClientModule` imports, and their own bespoke `angular.json` builder configs. The hard part isn't running `ng update`; it's reconciling every drift point so the schematic actually applies cleanly, then verifying nothing visually regresses after standalone components, the new control flow, or zoneless rendering are turned on.

What Tidra Does

1. Reads package.json, angular.json, and tsconfig.json to identify the current Angular major and the surface area each app uses
2. Bumps @angular/* packages to the target major and aligns peer dependencies (RxJS, TypeScript, zone.js, Node engines)
3. Applies the equivalent of ng update migrations in-tree: @ViewChild static defaults, HttpClientModule → provideHttpClient, control-flow rewrites where targeted
4. Converts eligible components to standalone and updates the bootstrap to bootstrapApplication where the target version supports it
5. Updates CI Node versions in .github/workflows/*.yml to match the Angular target's runtime floor
6. Opens a PR per repo summarising the migrations applied, any schematics that needed manual intervention, and the list of deprecated APIs still in use

Before & After

Customization Tips

• Target version: Specify the exact target major (e.g., Angular 18 vs. 19); schematics, control flow, and zoneless support differ meaningfully between adjacent versions.
• Standalone adoption: Decide up front whether to opt apps into standalone components as part of the bump or keep NgModules. Mixing the decision across repos creates inconsistent codebases.
• Material/CDK: If you use Angular Material or CDK, bump them in lockstep with @angular/core. Mismatched majors will fail peer-dependency resolution.
• Test coverage gate: Require ng test and ng build --configuration production to pass before merging. Production builds catch AOT-only template errors that dev builds miss.