feat: support angular 21

[lekhmanrus]

Summary by CodeRabbit

• Chores

  • Upgraded Angular-related build tooling and ESLint ecosystem to 21.x and updated supporting dev dependencies.

• Bug Fixes

  • Improved error message for missing pages to include the requested page identifier.

• Refactor

  • Streamlined component directive imports to improve tree-shaking and bundle size.
  • Adjusted TypeScript compiler libs configuration.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Upgraded Angular-related devDependencies to 21.0.0 and adjusted eslint/typescript-eslint versions; removed an npm devDependency. Replaced CommonModule with NgClass in a login component import. Changed the default page error message to include the requested pageId. Removed the lib entry from tsconfig.json.

Changes

Cohort / File(s)	Change Summary
Dependencies & Configuration package.json, tsconfig.json	Updated devDependencies: Angular packages and ng-packagr → 21.0.0; bumped @typescript-eslint package; removed npm-check-updates devDependency. Removed lib (e.g., ["ES2022","dom"]) from tsconfig.json compilerOptions.
Component Imports src/login/pages/login/login.component.ts	Replaced top-level import of CommonModule with NgClass and updated the component decorator imports array to use NgClass in place of CommonModule.
Error Message src/login/defaultPage.ts	Changed thrown error text in the default branch of getDefaultPageComponent to include the pageId: FTL page "${pageId}" not found!.

Sequence Diagram(s)

(omitted — changes are small and do not introduce new control-flow interactions that warrant a sequence diagram)

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Review package.json dependency version bumps for compatibility and any peer-range implications.
• Verify that replacing CommonModule with NgClass provides all required directives/providers for the login component and its template.
• Confirm the updated error message in defaultPage.ts is appropriate and does not leak sensitive values in production logs.
• Ensure removing lib from tsconfig.json does not break builds or alter runtime types (DOM APIs).

Poem

🐇 I hopped through packages, neat and bright,

NgClass snug where Common stood last night.
A page not found now speaks your name,
tsconfig trimmed to play the game.
Happy builds and tests take flight!

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The PR title 'feat: support angular 21' directly and clearly describes the main objective of the changeset - upgrading Angular dependencies and related packages to support Angular 21.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e8229ca and d7efd70.

⛔ Files ignored due to path filters (1)

• yarn.lock is excluded by !**/yarn.lock, !**/*.lock

📒 Files selected for processing (4)

• package.json (2 hunks)
• src/login/defaultPage.ts (1 hunks)
• src/login/pages/login/login.component.ts (2 hunks)
• tsconfig.json (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (2)

• src/login/pages/login/login.component.ts
• src/login/defaultPage.ts

🔇 Additional comments (1)

tsconfig.json (1)

1-32: Verify the lib removal doesn't break DOM type definitions.

The lib entry has been removed from compilerOptions. When not explicitly specified, TypeScript uses default type libraries based on the target, which may not include full DOM support. Since Angular components rely on DOM APIs (Element, Document, HTMLElement, etc.), this could cause type definition issues during compilation or development.

Verify that the build compiles without type errors and that no DOM-related type definitions are broken.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 61d2b8b and e8229ca.

⛔ Files ignored due to path filters (1)

• yarn.lock is excluded by !**/yarn.lock, !**/*.lock

📒 Files selected for processing (4)

• package.json (1 hunks)
• src/login/defaultPage.ts (1 hunks)
• src/login/pages/login/login.component.ts (2 hunks)
• tsconfig.json (1 hunks)

🔇 Additional comments (3)

src/login/defaultPage.ts (1)

152-153: Excellent addition of explicit error handling!

Adding the default case with an explicit error throw is a best practice. It ensures that any unknown pageId values are caught immediately with a clear error message, making debugging much easier. This also aligns well with the noFallthroughCasesInSwitch compiler option enabled in your tsconfig.

src/login/pages/login/login.component.ts (1)

1-1: Good optimization: importing only NgClass instead of CommonModule is valid.

Verification confirms the template uses only [ngClass] binding (found in two locations with provider.iconClasses). The template relies on modern Angular control flow syntax (@if, @for, @let) rather than old CommonModule directives, and doesn't use any CommonModule pipes. NgClass is correctly imported and sufficient for the component's needs.

tsconfig.json (1)

24-24: Now let me inspect the actual tsconfig.json to see its current state:

Verify that removing the lib compiler option is compatible with Angular 21.

When TypeScript target is set to "es2022", the lib defaults to ["dom", "es2022"], so DOM types will be included automatically. However, Angular's recommended tsconfig includes explicit lib configuration with ["es2020", "dom"], and best practice is that lib should be explicitly specified alongside target for clarity and to avoid relying on implicit defaults.

If the PR sets target: "es2022" and removes lib, DOM types remain available through TypeScript's default inference. However, explicit lib configuration is still recommended by Angular guidelines for maintainability.