feat: add Angular 22 support (non-breaking, keeps 18–21)#212
Merged
Conversation
Extends the supported Angular range from 18–21 to 18–22. - package.json: bump devkit upper bounds (architect <0.2300.0, core/schematics <23.0.0) and the @angular/cli peer to <23.0.0; v3.1.0 - README: update supported range to "Angular 18 to 22" - CI: add an Angular 22 ng new / ng add / ng deploy smoke test - tests: add angular-22.json fixture (real ng new v22.0.0 output) plus Angular 22 compatibility assertions No engine/builder changes needed: Angular 22's generated angular.json is structurally identical to 21 (@angular/build:application, no outputPath), which actions.ts already handles.
4 tasks
#211 rightly flagged that engines.node ">=18.0.0" is stale — no supported Angular actually runs on Node 18.0–18.18 (Angular 18's real floor is 18.19.1). It set "^20.19.0 || ^22.12.0 || >=24.0.0", but that is Angular 20/21's requirement and is too narrow here: it locks out Node 18/19 needed by the Angular 18/19 users this PR still supports, plus odd majors. Bump to a wide lower bound at the true floor of the oldest supported Angular (18 → 18.19.1). Angular CLI enforces its own stricter per-version Node gate, so we only need a sane floor, not a duplicate of it.
Member
Author
|
FYI @d-koppenhagen |
The workflow only triggered on push to main/big-update, so pull requests (including this one) received no CI at all. Add a pull_request trigger (targeting main) so PRs are validated before merge, plus workflow_dispatch for on-demand runs (becomes usable once this lands on the default branch).
Member
|
I see no reason at all to support a horribly outdated version of Angular. But since there are no changes in the logic (string outputpath is still possible), I'm okay with this! |
fmalcher
approved these changes
Jun 8, 2026
Member
Author
|
Fully agree. And the day a version actually costs us logic or workarounds, it's gone. But here it's zero added logic and the tests run themselves, so I'd rather keep the late-upgrading enterprise crowd happy for free than field "my build broke" issues. 😅 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds Angular 22 to the supported range without breaking changes — the existing v3 line keeps supporting Angular 18–21 and now also 22. Released as a minor bump (
3.0.3→3.1.0).What changed
src/package.json— extended upper bounds only:@angular-devkit/architect:<0.2200.0→<0.2300.0@angular-devkit/core/@angular-devkit/schematics:<22.0.0→<23.0.0@angular/cli:<22.0.0→<23.0.03.1.0README.md— supported range "18 to 21" → "18 to 22"..github/workflows/main.yml— added an Angular 22ng new/ng add/ng deploysmoke test alongside the 18–21 steps.src/test-fixtures/angular-22.json+angular-versions.spec.ts— new fixture (the realng newoutput from@angular/cli@v22.0.0, verified against the schematic source) plus an Angular 22 compatibility block and extended cross-version assertions.Why no engine changes
Angular 22's generated
angular.jsonis structurally identical to 21 (@angular/build:application,browser: src/main.ts, nooutputPath).actions.tsalready resolves the defaultdist/<project>/browserfor theundefined-outputPathcase, so no builder logic changes were needed.Testing
npm run build— cleannpm test— all suites pass, including the new Angular 22 fixture testsng new/ng deployagainst Angular 18–22.