Thanks to visit codestin.com
Credit goes to github.com

Skip to content

angular upgrade v18 -> v19 #2877

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Dec 9, 2024

Conversation

andre-steudel
Copy link
Contributor

Description

Update Angular to Version 19 and migrate Code to use Standalone Components. Standalone Components are used by default from Version 19 on. In a survey from the angular team "90% of developers said they are using this feature".
I still left the Angular Module for those who are still not using them.

Checklist

  • Created tests which fail without the change (if possible)
  • All tests passing (yarn test)
  • Extended the README / documentation, if necessary

@adumesny
Copy link
Member

adumesny commented Nov 21, 2024

while I appreciate the contribution I don't think forcing a minimum of Angular 18 (for @ syntax) or 19+ for standalone is wise decision. these 3 files are not tree shackable per say (always use all) so no benefit for standalone and break a lot of potential user.

today its angular 14 and I had people ask how to use an older version already (only the dynamic creation api needs tweaks, which I need to document if I didn't already).

forcing angular 18/19 is no-no in my book. I don't even have a proper package to rev and have external ng dependencies...

90% I don't buy it for existing large app. My work very large app is Ang18 and just dozens of large tree shackage are standalone. converting >2500 component is not easy nor automatic unless I missed something. heck can't even use esbuild+vite to run (still on webpack) at work which I've been trying to convert away due to very slow build but stuck...
now going on tangent... :)

@andre-steudel
Copy link
Contributor Author

while I appreciate the contribution I don't think forcing a minimum of Angular 18 (for @ syntax) or 19+ for standalone is wise decision. these 3 files are not tree shackable per say (always use all) so no benefit for standalone and break a lot of potential user.

Thanks for your quick reply. I was not aware that Angular 14 is still used :D
But actually Standalone components are supported in Angular since version 14 already. For the control flows you are right, I reverted the change.
And agreed there will be no performance gain but for applications which have migrated completely to standalone its nicer to use Standalone only.
And also with my changes the old way will still be supported so it's no breaking change for users.

But if you prefer to keep it in the old way, I can also revert the rest and we only do the Angular 19 Upgrade?

today its angular 14 and I had people ask how to use an older version already

I just made some tests and actually you only support Angular 16 or higher. I get some compiler errors in the older versions because of changes in the ComponentDefinition of Angular because the library was build with Angular 18. (with the currently released version without my changes)

90% I don't buy it for existing large app. My work very large app is Ang18 and just dozens of large tree shackage are standalone. converting >2500 component is not easy nor automatic unless I missed something.

Yeah I guess they meant that 90% have tried out the feature but are not fully migrated like you. Fyi there is also a migration:
ng generate @angular/core:standalone

@adumesny
Copy link
Member

I just made some tests and actually you only support Angular 16 or higher. I get some compiler errors in the older versions because of changes in the ComponentDefinition of Angular because the library was build with Angular 18. (with the currently released version without my changes)

oh that's a problem! I guess I am compiling with tsc to get d.ts out, but I'm also including the source code but not sure how would import those instead... might have to go back to ng14-16, though I am already using @ in the demos...
Does 19 make this even worse ?

the publish code need to be the lowest possible version support to open this lib to as many people as possible. even ng14 new api cleanup requirement could be in question, even though I love finally not having to create factories...

problem is I don't have a rev package for this, nor woudl I want to maintain multiple copies as GS code change require update to the wrapper. same repo to make this (and soon React) easier.

@andre-steudel
Copy link
Contributor Author

I did some more research. Angular libs are backward compatible but not forward compatible., So e.g. if you build your library with Angular 14, you can normally also use it in Angular 19. But the other way around is not officially supported and can break between the versions.

When building a library, use the minimum version of Angular that you would like to support. So if you want your library to be compatible down to v12 applications, use Angular v12 to build it.

Angular 14 Support

If you want to support Angular 14 you have to downgrade the library also to Angular 14 again. There were some breaking changes in the Angular API which results in the following error:

Error: node_modules/test/lib/test.component.d.ts:4:18 - error TS2707: Generic type 'ɵɵComponentDeclaration' requires between 7 and 8 type arguments.
static ɵcmp: i0.ɵɵComponentDeclaration<TestComponent, "lib-test", never, {}, {}, never, never, false, never>;

Angular 15 Support

Angular 15 actually works but the typescript version difference causes some build time errors:

gridstack.component.d.ts:123:84
Type '{ options: { alias: "options"; required: false; }; }' does not satisfy the constraint '{ [key: string]: string; }'.
  Property '"options"' is incompatible with index signature.
Type '{ alias: "options"; required: false; }' is not assignable to type 'string'.
static ɵcmp: i0.ɵɵComponentDeclaration<GridstackComponent, "gridstack", never, { "options": { "alias": "options"; "required": false; }; "isEmpty": { "alias": "isEmpty"; "required": false; }; }, { "addedCB": "addedCB"; "changeCB": "changeCB"; "disableCB":

I guess downgrading Typescript is also difficult and may not work because Angular also has a minimum typecript version. However I could get it running by disabling the typescript checks for libraries in the tsconfig.

{
  skipLibCheck: true
}

>= Angular 16 support

Seems to be good, even the Angular 19 Update would still be compatible with Angular 16

Conclusion

Probably the least maintainable effort is to stay at a lower Angular Version. And just change the package.json peerDependencies so no one gets warnings when installing the library.
Only when you need Features from new Angular Versions e.g. the drop of Factories update to a newer version.
However keep in mind that maybe typescript updates also could break the support for older versions.
A good reference is the version compatibility page from the angular docs.

@adumesny
Copy link
Member

maybe the best thing to do it go back to angular14 (as have info for ng13 and older), revert the demo @ code (not sure if we can publish 14 but use 18+ for demos) and keep your standalone work under 14.
I kinda wanted to use 16->17->18 as to test the new esbuild+vite thing I'm so desperatly need for my work project but didn't realized I made it angular 16+ requirement on users now.
.

@adumesny adumesny merged commit 503940d into gridstack:master Dec 9, 2024
@adumesny
Copy link
Member

adumesny commented Dec 9, 2024

hopefully best of both now #2889

@andre-steudel andre-steudel deleted the feature/angular-19 branch December 9, 2024 07:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants