Angular 12

Angular 12 continued the Ivy-era architecture and made the older View Engine toolchain deprecated, signaling that applications and libraries needed to be compatible with Ivy. It added support for newer TypeScript tooling, moved the Angular language service toward its Ivy-based implementation, and improved compiler and CLI behavior. The CLI made stricter project settings the default for newly generated applications, helping catch type and template issues earlier. It also deprecated Protractor as Angular’s end-to-end testing solution and deprecated Internet Explorer support, so teams were expected to plan replacements for those dependencies. Angular is not AngularJS: AngularJS is a separate, earlier framework with its own versions and its own end of life. Teams actually running AngularJS should use /technology/angularjs.

Angular 12 has reached end of life, so remaining on it means relying on an unsupported framework line with no vendor fixes for newly identified defects or security issues. Its deprecated View Engine, Protractor, and Internet Explorer paths become increasingly difficult to sustain as libraries, browsers, build tools, TypeScript versions, and CI environments move on. Dependency upgrades may be blocked by Angular 12’s supported peer-dependency ranges, while postponing the move can turn a routine framework upgrade into a larger migration involving source changes, test-runner replacement, browser-policy changes, and build-pipeline repair. Unsupported transitive dependencies and audit findings can also require compensating controls or exception handling.

Inventory the workspace’s Angular packages, Angular CLI version, TypeScript and RxJS versions, browser targets, custom builders, and third-party libraries before choosing a currently supported Angular target. Remove or replace View Engine-era libraries where possible, confirm that internal libraries compile and package correctly for Ivy, and replace Protractor with a maintained end-to-end testing approach before it becomes a blocking dependency. Use the official Angular update guidance for each major-version transition, run the matching ng update migrations in a dedicated branch, and upgrade application and CLI packages together. Build and test after each step, including production builds, unit tests, end-to-end tests, server-side rendering if used, and the browsers your organization supports. Address strict template and TypeScript diagnostics rather than disabling them broadly, then update CI images, lockfiles, and deployment artifacts once the migrated application is validated.