Angular 11

Angular 11 built on the Ivy-based Angular architecture already established in earlier releases, with emphasis on developer tooling and build workflow rather than a wholesale framework redesign. The CLI improved build diagnostics and production build behavior, including automatic inlining of external fonts for supported production builds. The release line added support for TypeScript 4.0 and tslib 2, improved the Angular Language Service, and expanded component test-harness capabilities. It also introduced or advanced stricter typing and migration work around deprecated APIs, so applications could expose template, compiler, and dependency assumptions that had previously passed unnoticed. Angular is not AngularJS: AngularJS is a separate, earlier framework with its own versions and its own end of life. Teams running AngularJS should use /technology/angularjs instead.

Angular 11 has reached end of life, so Angular no longer provides fixes for defects or security issues in this release line. The practical risk is broader than the framework package itself: supported versions of TypeScript, Node.js, browser tooling, test runners, and third-party Angular libraries increasingly move beyond Angular 11's peer-dependency and compiler expectations. This can leave teams pinned to older build tooling, forced to use dependency overrides, or unable to take routine security updates without a larger migration. Unsupported tooling also makes CI failures, browser compatibility issues, and future upgrade work harder to diagnose, because each deferred major-version migration accumulates its own API removals and required code changes.

First, establish a reproducible Angular 11 baseline: update within the 11 line as far as the workspace permits, lock dependencies, run a production build, and record the results of unit, integration, and end-to-end tests. Inventory custom builders, schematics, Angular libraries, TypeScript settings, RxJS usage, browser targets, and packages with Angular peer dependencies; these are common upgrade blockers. Then use the Angular Update Guide and run ng update migrations through successive major versions, validating the application after each step rather than combining all changes into one unreviewable deployment. At every target version, align the supported Node.js, TypeScript, and RxJS ranges before resolving library peer-dependency conflicts. Replace deprecated APIs and unsupported tooling identified by migrations, test production bundles and server-side rendering if used, and deploy the final supported target through a staged rollout with rollback coverage.