skip to content

Your Angular app is on v20 while v22 is current; how would you plan the upgrade, and why not jump straight to v22?

level: seniorimportance: must knowfreq 52%

answer

  1. policy says one step each
  2. the update tool refuses the jump
  3. TypeScript and Node move per major
  4. an LTS end date sets the deadline

basics

~20 s

Upgrade one major at a time, v20 to v21 then v21 to v22, because Angular's policy supports updates only within one major and ng update refuses multi-major jumps. v20's LTS ends 2026-11-28, so plan both hops before then.

solid answer

~40 s

Angular supports updating only from a version **within one major** of the target, so the path is **v20 -> v21 -> v22**, each as its own step; `ng update` refuses a multi-major jump and tells you to migrate each major individually. Each hop runs that major's migrations and has its own prerequisites: v21 needs TypeScript 5.9, v22 needs TypeScript 6.0 and drops Node 20. There is a deadline: v20's LTS ends **2026-11-28**, after which it gets no security patches. Before each hop I would move to the latest minor of the current major, clear deprecated APIs, read the changelog's breaking changes, and confirm that third-party libraries support the next major. Then build, test and ideally ship each hop separately, so a regression points at one major's changes, not two.

code

bash · 7 lines
bash
# Hop 1: v20 -> v21 (TypeScript 5.9 required)
ng update @angular/core@21 @angular/cli@21
# build, test, release

# Move Node to ^22.22.3, ^24.15.0 or ^26.0.0 first
# Hop 2: v21 -> v22 (TypeScript 6.0 required)
ng update @angular/core@22 @angular/cli@22

go deeper

for a junior

Remember the rule: Angular upgrades go one major at a time, and each version has minimum Node and TypeScript versions.

for a middle

Explain why skipping a major breaks the per-major migrations, and name the prerequisites that change between v20, v21 and v22.

for a senior

Lay out the plan with dates: the v20 LTS deadline, deprecation clean-up, library readiness, one release per hop and the runtime upgrade in between.

for a principal

Decide whether to stop at v21 or push to v22 given library readiness and team capacity, and how to prevent the app falling two majors behind again.

An app two majors behind is the most common upgrade scenario an interviewer builds, because it tests whether you know the rules of Angular's release policy and can turn them into a plan with dates. ## Why the jump has to be split Angular's policy says you can update to any **supported** version as long as the version you update **from** is **within one major** of the version you update to. To cross several majors you perform **each update one major version at a time**. The tooling enforces it: when `ng update` sees a jump of more than one major for a package, it stops with the message that updating multiple major versions at once is not supported, and names the next major to update to. The reason is how breaking changes are delivered. Each major ships its own **migrations**, written against the code as it looks on the previous major. The v21 migrations expect v20 code; the v22 migrations expect v21 code. Skipping v21 would skip the rewrites that the v22 ones assume already happened. ## The deadline The v22.2 support table shows: | Version | Status | LTS ends | | :-- | :-- | :-- | | v22 | Active | 2028-06 | | v21 | LTS | 2027-06 | | v20 | LTS | **2026-11-28** | So an app on v20 in September 2026 is still receiving security patches, but only for about two more months. After that date a newly found vulnerability in v20 will not be patched. Landing on v21 buys time until mid-2027; landing on v22 buys it until mid-2028 and puts you on the only major still getting regular updates. ## Prerequisites that move with each hop From the version compatibility table: | Angular | Node.js | TypeScript | | :-- | :-- | :-- | | 20.2.x / 20.3.x | ^20.19.0, ^22.12.0 or ^24.0.0 | >=5.8.0 <6.0.0 | | 21.x | ^20.19.0, ^22.12.0 or ^24.0.0 | >=5.9.0 <6.0.0 | | 22.0.x | ^22.22.3, ^24.15.0 or ^26.0.0 | >=6.0.0 <6.1.0 | Two consequences: - **TypeScript moves on every hop**: 5.9 for v21, then 6.0 for v22. Upgrading TypeScript early, on the latest 20.x minor, removes one variable from the first hop. - **Node 20 is not supported by v22.** CI images and developer machines have to be on Node 22.22.3+, 24.15+ or 26 before the second hop. ## A step-by-step plan 1. **Stabilise the starting point.** Update to the latest v20 minor and patch, and make the test suite green there. 2. **Clear deprecations.** Anything deprecated in v20 or earlier is a candidate for removal in v21 or v22. Fix it while both old and new APIs still work. 3. **Check the ecosystem.** Every library with an Angular peer dependency must publish a version supporting v21, and later v22. The slowest dependency often sets the schedule. 4. **Hop to v21.** Read the 21.0.0 breaking changes (for example, zoneless became the default for applications), run the update and its migrations, build, test, and ideally release. 5. **Update the runtime.** Move Node and CI images to a version v22 supports. 6. **Hop to v22.** Read the 22.0.0 breaking changes (for example, components without a `changeDetection` value became `OnPush` by default), run the update, build, test, release. 7. **Only then modernise optionally.** Adopting new APIs is separate work; mixing it into the hops makes regressions harder to attribute. ## Keeping the hops honest - **One major per pull request.** Small, reviewable diffs; a failing test points at one set of changes. - **Ship between hops when possible.** Production traffic on v21 before starting v22 catches runtime regressions that tests missed. - **Use the Angular Update Guide** on angular.dev for the from/to pair; it gives step-by-step instructions for moving from one major to the next. ## Mistakes interviewers listen for - Editing `package.json` to v22 by hand and fixing compile errors one by one: it skips every automatic migration. - Planning both hops and a feature refactor as one big-bang branch. - Forgetting that the TypeScript and Node floors move, and discovering it in CI. - Treating "still in LTS" as "no hurry" when the LTS end date is weeks away.

  • What exactly happens if you run ng update @angular/core@22 on a v20 workspace?
    It refuses. The update command detects a jump of more than one major and reports that updating multiple major versions at once is not supported, telling you to run the update to the next major (v21) first. That matches the policy of updating one major at a time.
  • Why clear deprecated APIs before the hop instead of after it?
    Because a deprecated API may be removed in the next major. Before the hop both the old API and its replacement exist, so the change is a safe refactor on a green build; after the hop the old API may be gone, and the fix happens on a broken build mixed with the upgrade's own changes.
  • What should you do if a key third-party library does not support v22 yet?
    Finish the v21 hop, which moves you off v20 before its November 2026 LTS end, and wait on v21 while it is in LTS until mid-2027. Meanwhile track the library's releases or plan a replacement; do not force install it against an unsupported peer range.

saying these in an interview costs you the question

  • You can update straight from v20 to v22 if you fix the compile errors.
  • Bumping the versions in package.json is the same as running the update.
  • Node and TypeScript versions do not matter for an Angular upgrade.
  • An app in LTS is fine indefinitely, so the upgrade can wait.
  • Both hops and a big refactor belong in one branch to save time.