briebug / ngrx-auto-entity

NgRx Auto-Entity: Simplifying Reactive State
https://briebug.gitbook.io/ngrx-auto-entity/
Other
66 stars 12 forks source link

Preparing for v12 and v13/14 releases #222

Closed jrista closed 1 year ago

jrista commented 2 years ago

NgRx Auto-Entity v12 Forthcoming Release

The day is nearly here for an official stable release of NgRx Auto-Entity. This has been a side project and hobby of mine for quite some time now, and it has been tough to get the time to work on it lately. You would have thought the pandemic lockdowns would have freed me up, however the opposite seems to have been true. Work consumed my life.

This year, we've finally managed to get the code well tested enough, both with unit tests as well as in real-world cases with various clients, that we finally feel it is stable and debugged enough for a reliable official release. As part of releasing Auto-Entity we will be aligning versions with the version(s) of Angular that are supported. For this initial release, the version will be v12.0.0, and it will support all versions of Angular from 12 back to 9. Older versions of Angular or NgRx are, sadly, not supported due to changes in how the Angular compiler works, and some internal changes in how NgRx works.

NgRx Auto-Entity v12.0.0-beta.1 has been released today. This version includes some minor bug fixes, as well as additional unit testing. Barring any major issues, we will release v12.0.0 officially soon!

Source Code Features

Internally, Auto-Entity does not utilize newer JS or TS features such as optional chaining and similar newer language features. This was to maintain as much backwards compatibility as possible. We have invested in more verbose code to ensure that compatibility is threaded throughout the library. This can, however, potentially bloat the library a bit from a bundle size.

Other things about NgRx Auto-Entity also bloat the library a bit, from a bundle size, including some early ideas about making it easy to configure different subsets of Auto-Entity effects, in the event that you wished to take control of one aspect or another of the functionality. As Auto-Entity has grown, some of these features have lost their value. Further, the most common use cases by far rarely ever change the default effects configuration.

As we turn our attention to v13 and beyond, we will be looking at ways to optimize the code base, remove features and functionality that are seldom used or otherwise just dead code bloating the bundle. Hopefully this will help us lean things up a bit in the future.

NgRx Auto-Entity v13/14 Transition

Now that v12.0.0 is officially becoming a reality, we are transitioning our efforts to supporting Angular v13 and v14. Depending on the breaking changes for each of these versions, we may work on and ultimately release two versions of Auto-Entity to support each. Hopefully a single version will do for both.

Supporting Angular and NgRx v13, we will also have to upgrade our library to support RxJS v7 and beyond, which itself is a breaking change. As we have no option but to avoid breaking changes with this transition, we will be looking at ways to reduce the amount of code in the library wherever we can, and minimize the bundle size. There are some features of Auto-Entity as mentioned above that may not be necessary, and with newer versions of TypeScript we will be able to support terser code as well.

Stronger Typing

Another change we will be trying to make is supporting maximum TypeScript Strict mode, wherever we can, to maximize our compile-time checking capabilities. Auto-Entity is written in a very functional manner, which has the potential for extensive code reuse, and as we get deeper into strongly typed code, we will also be looking for ways to leverage types and functional programming to reduce code volume even further, whenever possible.

Potential Breaking Changes

These changes will undoubtedly lead to additional breaking changes. One of our goals has always been to maintain as much backwards compatibility as possible. When it comes to our official public interface, we will do everything in our power to minimize changes there, and maximize backwards compatibility. The key goal here is to limit the amount of effort required for anyone upgrading from Angular/NgRx/Auto-Entity 12 to a newer version. In some cases, we may have stronger types, however the names of publicly exposed code features should remain the same. In some cases, some public code features may be removed, where we deem them unnecessary in the future.

Removal of Deprecations

Some minor features may be removed from the featureset of the library, such as custom sorting options, due to the deprecation of parameterized selectors in NgRx. These features are currently flagged as deprecated and slated for removal in v12, and will in fact be removed in v13 and later.

Timeframes

We expect Auto-Entity v12 to reach non-beta final release soon. We would like the beta to simmer for a little while and get some usage, however the only changes are minor bug fixes that came out of more extensive unit testing, issues which do not seem to have been encountered in any of our running production products as of yet. We do not foresee any issues preventing a final release within the next couple of weeks.

For v13 and up, we hope to work through the hardcore upgrade issues such as ivy compilations, transition from tslint to eslint, rxjs 7+, and current versions of ngrx, over the next month or two. Depending on just how extensive the breaking changes are, it may take a little longer, however we hope that the most egregious issues will just be ivy and upgrading rxjs to version 7. Those will hopefully not take too terribly long. We intend to have a beta version of this next incarnation of the library ready this summer, hopefully midsummer at the latest.

Thank you for your support! If you have any questions, feel free to voice them below!

Inexad commented 2 years ago

Hi @jrista,

Hope all is good ! How's the progress for V13?

Regards.

jrista commented 2 years ago

@Inexad We have released a beta of v14, which supports angular 13 and 14. We did run into a build issue with it in one of our own projects, so its not ready for prime time. We are definitely working on it, though!

You can find the v14 release in npm under the beta tag if you want to give it a whirl.

jrista commented 2 years ago

For reference:

https://github.com/angular/angular/issues/46748

It appears that we may have to build versions of the lib for each version of Angular we wish to support. As it stands, Angular 14 should work with the v14 beta version of NgRx Auto-Entity. For Angular 13 support, I'll work on getting a specific build created for that version of Angular. Not entirely sure how we are going to handle that in the long term...Angular is certainly not making it very easy on library developers with this lack of backwards compatibility in their builds...

Inexad commented 2 years ago

Thanks for the update!

So as long as we use Angular 14 it should be fine using the beta version you released?

jrista commented 1 year ago

@Inexad Sorry for the late response...I didn't receive a notification of the last message. Right now, the v14 beta should work with Angular 14, yes.

To give you a heads up, I am thinking we may have to kind of invert our original plans for versioning. Because Angular Ivy builds now support "forward" versions, instead of releasing versions for the newest version of angular with "backwards" compatibility, we may instead have to release versions for the oldest Angular Ivy that will work, and support "forward" compatibility.

To that end, I suspect what will happen is the following:

The tricky part in all of this is Ivy. Because Google opted to allow build artifacts to change from one version of Angular to the next with Ivy, it put an odd burden on library developers to support M-N versions of Angular, with M being the OLDEST version that supports Ivy and any other critical libraries (like RxJs), and N being the forward looking "newest" version that supports Ivy and the same versions of those critical libraries. It makes building Angular libraries a lot trickier than it was before.

Inexad commented 1 year ago

Ok, thanks for this info!

We will start upgrading our systems to v14, will be very nice to use the latest auto-entity with it. We kinda been stuck in angular 12 because we are a bit dependent on this package at the moment (not optimal, but the time save is worth it for us).

Regards

jrista commented 1 year ago

Sounds good, @Inexad. Feel free to keep me appraised of any issues that you encounter as you work on upgrading to NG14 and NgRx Auto-Entity 14 beta. I'll try to tackle any bugs ASAP for you guys.

jrista commented 1 year ago

Just an update. Been working on a v13 version of NGRX Auto-Entity that would be compatible with Angular 14, and maybe 15. This has not yet been released due to peer dependency quirkiness. Since we are now potentially going to get hard errors around peer deps, I am trying to figure out if we can create more...nebulous, or dynamic, version ranges. I don't really want to say we support Angular 15 yet, although technically I think it would work. I am also not certain yet that trying to support angular 14 is working properly either. It is a tricky scenario...usually, compatibility is "backwards", but Angular has created this oddball scenario where library compatibility is "forwards" instead...and, semver doesn't really seem to have effective support for that.

jrista commented 1 year ago

For the record, the current version of Auto-Entity has been tested quite extensively with Angular v13 and v14. We have had some usage with v15, and it seems to function correctly there as well, although use cases there haven't been as extensive. At the current time we have not tested with Angular v16, however unless the Ivy instruction sets we use with Auto-Entity have changed, then Auto-Entity v13 should remain compatible with Angular v16.

For now, I'm going to close this thread, as the question about Angular 13 and 14 support has been resolved, and support is there. If we encounter support issued with newer versions of angular, newer threads to address those specific versions should be created.