[SriramaDanturthi]

PR Checklist

Please check if your PR fulfills the following requirements:

• Tests for the changes have been added: N
• Docs have been added / updated: N
• Does this PR introduce a breaking change? Y
• I have linked any related GitHub issues to be closed when this PR is merged? N

Describe the new behavior?

Updates @tylertech/forge-angular to Angular 22 (v8.0.0).

Dependencies & tooling

• @angular/*, @angular/build, @angular/cli, @angular/compiler-cli, ng-packagr → ^22.0.0
• typescript → ~6.0, zone.js → ~0.16
• Library peerDependencies → >=21.0.0 < 23.0.0

Code migrations (required by Angular 22 API removals)

• DynamicComponentService rewritten to use createComponent / ViewContainerRef.createComponent — ComponentFactory and ComponentFactoryResolver were removed in v22.
• Demo lazy-load examples (dialog, bottom-sheet) switched from Compiler + NgModuleFactory to direct dynamic import() of the standalone components; obsolete wrapper NgModules deleted.
• Removed the deprecated baseUrl from tsconfig.json (hard error under TypeScript 6.0).

Consumer migration

• Added an ng update migration (update-8-0-0) that scans consumer apps and reports any DynamicComponentService.create() call sites relying on the removed APIs (file + line), so they can be fixed manually.

⚠️ Breaking changes

• Requires Angular 22.
• DynamicComponentService.create() signature changed:
  • Before: create<T, K>(component: Type<T> | ComponentFactory<T>, target?, injector?, moduleRef?: NgModuleRef<K>)
  • After: create<T>(component: Type<T>, target?, injector?)
  • The ComponentFactory overload and the moduleRef argument are gone. Pass a component Type and (optionally) a module-scoped Injector.

Additional information

Consumers upgrade with:

​bash ng update @angular/core@22 @angular/cli@22 ng update @tylertech/forge-angular ​

The forge migration then lists any affected DynamicComponentService.create() call sites to update.

[bolt-new-by-stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[DRiFTy17]

@SriramaDanturthi Thank you for putting this together! It looks great as an initial pass.

Could you also bump the node version for CI in the workflows?

For the PR builds, we need to add the following here:
https://github.com/tyler-technologies-oss/forge-angular/blob/main/.github/workflows/build-pr.yml#L16

with:
  NODE_VERSION: 25

Same for these:

• https://github.com/tyler-technologies-oss/forge-angular/blob/main/.github/workflows/build-release.yml#L48
• https://github.com/tyler-technologies-oss/forge-angular/blob/main/.github/workflows/build-release.yml#L96
• https://github.com/tyler-technologies-oss/forge-angular/blob/main/.github/workflows/build-release.yml#L106

That should be all you need to do to get the build to pass, but feel free to make any other adjustments as you see fit.

These workflows will be consolidated soon into the monorepo, but for now they are using the legacy shared workflows still...

[Ross-Blakeney]

The demo app should be kept on latest-1 version instead of latest.
The readme version matrix should be updated.

[Alanoll]

Are the changes really v22 specific? Do we really need to bump the minimum version of the supported Angular cores?
I know they finally removed ComponentFactory, but the replacements have been there a few versions.

[SriramaDanturthi]

@SriramaDanturthi Thank you for putting this together! It looks great as an initial pass.

Could you also bump the node version for CI in the workflows?

For the PR builds, we need to add the following here: https://github.com/tyler-technologies-oss/forge-angular/blob/main/.github/workflows/build-pr.yml#L16

with:
  NODE_VERSION: 25

Same for these:

• https://github.com/tyler-technologies-oss/forge-angular/blob/main/.github/workflows/build-release.yml#L48
• https://github.com/tyler-technologies-oss/forge-angular/blob/main/.github/workflows/build-release.yml#L96
• https://github.com/tyler-technologies-oss/forge-angular/blob/main/.github/workflows/build-release.yml#L106

That should be all you need to do to get the build to pass, but feel free to make any other adjustments as you see fit.

These workflows will be consolidated soon into the monorepo, but for now they are using the legacy shared workflows still...
Addressed these

[SriramaDanturthi]

The demo app should be kept on latest-1 version instead of latest. The readme version matrix should be updated.

demo app downgraded to angular 21 and readme version is updated

[SriramaDanturthi]

Are the changes really v22 specific? Do we really need to bump the minimum version of the supported Angular cores? I know they finally removed ComponentFactory, but the replacements have been there a few versions.

these are specific to angular 22 only

[Alanoll]

Are the changes really v22 specific? Do we really need to bump the minimum version of the supported Angular cores? I know they finally removed ComponentFactory, but the replacements have been there a few versions.

these are specific to angular 22 only

I don't believe you understand what I'm asking. Is there a reason for the forced Angular v22 bump, that will prevent projects still on v20 from easily upgrading?

The big change from the API surface area was removing deprecated Angular api usage, but your replacement api usage looks to have been available back in v20 as well. So could we NOT bump the minimum Angular version but just extend it.

[sriramasdanturthi]

Are the changes really v22 specific? Do we really need to bump the minimum version of the supported Angular cores? I know they finally removed ComponentFactory, but the replacements have been there a few versions.

these are specific to angular 22 only

I don't believe you understand what I'm asking. Is there a reason for the forced Angular v22 bump, that will prevent projects still on v20 from easily upgrading?

The big change from the API surface area was removing deprecated Angular api usage, but your replacement api usage looks to have been available back in v20 as well. So could we NOT bump the minimum Angular version but just extend it.

I believe its -1 and current not -2 and current reader also has same pattern. Am I missing something ?

[MikeMatusz]

FYI, did a quick audit of dynamicComponentService.create through a GH search of the org, and while it could certainly have missed things, I only found one usage with an NgModuleRef (incidentally in one of my team's applications) and it's an easy fix, so I definitely don't have any concerns about removing support for it. Angular does still expose a createNgModuleRef function which can be used to dynamically create components from NgModules, but based on the audit, I think if the need ever came up, it would probably make more sense for the application to just one-off it.

[Alanoll]

I believe its -1 and current not -2 and current reader also has same pattern. Am I missing something ?

This may be a larger discussion then for @DRiFTy17 and his team then. I understand the current pattern documented in the CONTRIBUTING.md file, but according to Angular's support documentation, v20 is supported for fixes until 2026-11-28, since v22 was just released a week or so ago.

I just didn't see any significant reasons in this PR that would necessitate leaving v20 behind yet (since the replacement APIs exist in it). Maybe the next forge-angular release would finally drop support if desired.

[DRiFTy17]

I believe its -1 and current not -2 and current reader also has same pattern. Am I missing something ?

This may be a larger discussion then for @DRiFTy17 and his team then. I understand the current pattern documented in the CONTRIBUTING.md file, but according to Angular's support documentation, v20 is supported for fixes until 2026-11-28, since v22 was just released a week or so ago.

I just didn't see any significant reasons in this PR that would necessitate leaving v20 behind yet (since the replacement APIs exist in it). Maybe the next forge-angular release would finally drop support if desired.

We support "current - 1" because Angular guarantees API compatibility following that pattern. They may continue to support older releases for a longer period of time, but that's separate from API compatibility.

With that said, if our package is still compatible back to v20, then I'm all for keeping the minimum version as v20 to avoid disruption for consumers while introducing support for v22 at the same time. Our local demo site would need to stay on v20 in that case to ensure that we can test this package properly and avoid introducing new v22 APIs that could break v20 apps.

On the flip side, we usually stick to the "current - 1" pattern to not only make sure we are taking advantage of the most recent APIs from Angular, but also to help nudge teams to keep their apps up to date.

[SriramaDanturthi]

Is this good to merge ?

[Alanoll]

On the flip side, we usually stick to the "current - 1" pattern to not only make sure we are taking advantage of the most recent APIs from Angular, but also to help nudge teams to keep their apps up to date.

I definitely get this, but speaking from a team that waits till the very end of the cycle, we'll lose 6 months (this time) of potential forge updates until we can schedule a full Angular upgrade. It's just a balancing act like always.

[DRiFTy17]

On the flip side, we usually stick to the "current - 1" pattern to not only make sure we are taking advantage of the most recent APIs from Angular, but also to help nudge teams to keep their apps up to date.

I definitely get this, but speaking from a team that waits till the very end of the cycle, we'll lose 6 months (this time) of potential forge updates until we can schedule a full Angular upgrade. It's just a balancing act like always.

@Alanoll I can understand that for sure! I don't want this package to be a bottleneck, or a blocker by any means. I would definitely prefer that we take the approach of broad support wherever possible. This package doesn't need to be on the bleeding edge unless it's holding up consumers from implementing a new feature of Angular.

[DRiFTy17]

Is this good to merge ?

@SriramaDanturthi I would just like to make sure that everyone is in agreement before we merge this.

For everyone else (@MikeMatusz, @Ross-Blakeney, @samrichardsontylertech, @Alanoll), could you please review once more and make any final comments and/or give it an approval if you're all set?

[Alanoll]

Just leaving my comments about for the changes to continue v20 support.

[sriramasdanturthi]

Just leaving my comments about for the changes to continue v20 support.

if every one agrees to v20 i will update pr otherwise leave as is

[DRiFTy17]

if every one agrees to v20 i will update pr otherwise leave as is

That would be my vote if you don't run into any issues with it. It will at least unblock everyone for the short term.

Any objections @samrichardsontylertech, @MikeMatusz, @Ross-Blakeney?

As a side note, we can certainly also create version branch of minimum v21 or v22 support if there is a real need to do so. It just introduces maintenance for multiple versions in this package which is cumbersome to keep up with, but it helps keep this package on the modern APIs as well without worrying about support for older versions...

[sriramasdanturthi]

if every one agrees to v20 i will update pr otherwise leave as is

That would be my vote if you don't run into any issues with it. It will at least unblock everyone for the short term.

Any objections @samrichardsontylertech, @MikeMatusz, @Ross-Blakeney?

As a side note, we can certainly also create version branch of minimum v21 or v22 support if there is a real need to do so. It just introduces maintenance for multiple versions in this package which is cumbersome to keep up with, but it helps keep this package on the modern APIs as well without worrying about support for older versions...

Its working in angular 20. but keep in mind this version has some braking changes we cant do 7.3.x it has to be 8.0.0

[sriramasdanturthi]

changed to v20 now please review again

[MikeMatusz]

I don't know of any Angular 21 features we urgently need to adopt in this library, so as long as these built packages work fine in both Angular 20 and Angular 22 apps, I don't object to the larger window this time.

But as Kieran said, Angular doesn't guarantee compatibility across two major versions. Given the lack of automated or formalized manual testing in this library, I'm not sure the existence of the demo page alone really provides a strong enough guarantee that everything is working properly. It doesn't even have examples of every component, and definitely not every configuration, so there is some risk when we do this.

Probably would be interesting to know more statistics on what versions are in use and what cadences everyone uses. In Public Safety, we try to stay on the latest-1, though it definitely makes sense for foundational libraries like this to support upgrading as soon as possible. It's also possible to run the schematic for the previous version of forge-angular to pick up new Forge features as necessary. Adds a little overhead, but if we could automate, or do get enough dedicated resourcing, maybe it could be achievable to still support teams on latest - 2 if that represents a large enough group.

[SriramaDanturthi]

build issues resolved please check

[Ross-Blakeney]

I've been separated from Forge for so long, my opinion doesn't really count.

Some observations that come to mind. This is more for an established and mature lib with governance. I have no idea how viable any of this is for the Forge community of devs.

• Compatibility is not mechanically proven.
• The fact that versioning is being debated on this PR suggests the policy is ambiguous.

Forge could aim to add some mechanics around this.

• CI version test matrix to prove compatibility
• Test infra is there but tests are needed. This goes hand-in-hand with the above bullet.
• A mechanical support policy agreed on by all stakeholders. Not set in stone, but rigid enough that it doesn't change due to comments on a PR.
• Lint rules and enforcement that prevent use of unsupported APIs

I have no idea how Forge is governed or managed. Just a shopping list of wider lib governance concepts.

Reality

Angular only guarantees API compat across one major, so not being able to prove ng20 support mechanically is the real risk here. That said, if folks are blocked we can't leave them blocked with no path forward. More a sign of the need for governance than anything.

So it seems there is no choice today and ng20 is required to unblock teams.

[SriramaDanturthi]

@DRiFTy17 @Alanoll @MikeMatusz please take a look at this pr

[DRiFTy17]

@SriramaDanturthi I apologize for the delay, I'm traveling currently, but these changes look good as far as version support for now to get you unblocked. We can cut another version soon with a minimum supported version bump to avoid the legacy API support, but for now I think this will suffice.

Unless anyone has any objections, I'm fine with merging this.

[github-actions]

🚀 PR was released in v9.0.0 🚀