carbon-design-system
Use new angular features
I'm interested in contributing but I also have some questions.
Do you intend to move to standalone components and the new control flow syntax?
Is there a formatter I should use?
Hey @tom-wegener, sorry for the late response, I was on vacation.
We plan on moving to the standalone components in v7, in our next branch (targeting v6 release), we have upgraded to the new control flow syntax and are preparing to go zoneless (not guaranteed - but definitely step in the right direction). We are currently migrating components to OnPush strategy.
You can follow the progress and contribute here: https://github.com/carbon-design-system/carbon-components-angular/issues/3066
We want v6 to be more of a integration release, just upgrading library version to Angular 18. v7 will be a bigger release where we will migrate to standalone + carbon 12.
Hey, thank you for your response and for the information and no problem that it was a bit late, vacations are important. This helps with understanding your plan and where I could contribute, thank you.
We want v6 to be more of a integration release, just upgrading library version to Angular 18. v7 will be a bigger release where we will migrate to standalone + carbon 12.
@Akshat55 , do you mind to explain why this project has a different version of the Carbon Design System itself?
I'm asking because the React component is v11 as well as Carbon.
@cvgaviao
Most of the carbon packages do not follow the carbon versioning, at least not anymore?
carbon react is v1.76 carbon styles is v1.75 (There are a few carbon packages that use v11 for major version)
This is mainly because each framework has a different update schedule, angular releases multiple versions per year, while react will release 1 version every 2 years?
In order to keep up with the angular changes, we have to release more breaking changes, so we can't wait for a new carbon release in order to release a new major version. So with v6, it'll mainly be an angular version bump.
Sometimes, we may have to release a breaking change to resolve an issue which would require a major version bump. We have to do this if we want to follow semantic-versioning best practices.