openng/cashew first version scope

[geromegrignon]

Description

We could release the first new version as a way for people to migrate form ngneat to openng scope but it would not bring direct value. The library is set to support "@angular/core": ">=17.0.0" so it would not bring restrictions/changes from an Angular project point of view.

We lost open issues/PRs with the ngneat GitHub repo removal so we do not have a clear vision about community expectations.

One aspect we can still work on for this first version is modernizing the codebase, to embrace Angular best practices, adopting signals for example and @Service. The latter means we would need to update the peerDependency to "@angular/core": ">=22.0.0" obviously.

Changes will require to assert there are appropriate unit tests to cover their usage to prevent any regression.

@valeriocomo

[drdreo]

I was one of the last contributors to the ngneat version. If i recall correctly, open issues were just 2-3 neglected ones, no open PRs. If i can help out in any way, let me know

[geromegrignon]

@valeriocomo see above message in case you need some help and collaboration!

[valeriocomo]

I would lean towards making the first release a pure migration release, without introducing behavioral or API changes. Keeping the current peer dependency (@angular/core >=17) would make the transition from @ngneat to @openng as smooth as possible while preserving compatibility for existing users.

As an experiment, I upgraded the entire project from Angular 20 to Angular 22 on a feature branch. The build passes and the full test suite is green, so moving to Angular 22 does not appear to introduce any issues from a technical standpoint.

I also evaluated adopting the new @Service decorator. In this library, all services are currently provided manually using the useClass pattern, so we would need to use @Service({ autoProviding: false }) instead of @Injectable. The Angular documentation covers this approach here: https://angular.dev/guide/di/creating-and-using-services#opting-out-of-automatic-provisioning.

That said, I think adopting @Service in the first release would be premature since it is only available starting with Angular 22, which would force us to raise the minimum supported Angular version without providing much immediate value to users.

Regarding Signals, I haven't yet identified compelling places where they would improve the implementation. Their adoption would likely require extending the public interface of some services (for example HttpCacheManager), so I think it deserves a separate discussion rather than being part of the initial migration release.

[drdreo]

As I've done some contribution to this before, I'd agree. Keep the v1 as the ngneat migration. As far as this library goes, it does not provide any UI logic where consumers would benefit from signals. Most logic lives within the http context life-cycle where I wouldn't see a signal advantage.
For services I also think the new @service decorator is neat for global services, but most here are scoped anyways not adding much if we convert.

Although bumping to v22 makes sense, afaik this never depends on much Angular internals, at least not from what they have changed.

[geromegrignon]

Hi @valeriocomo and @drdreo , i'm fine with releasing the first version as a migrationversion, not adding enhancements or features and using the same compatibility version policy as the latest @ngneat/spectator version.

[valeriocomo]

I couldn't agree more with you @geromegrignon

[geromegrignon]

@valeriocomo I'm waiting on feedback from community members about a semantic-releasesetup to facilitate release/changelog creation, and we should be able to release the first version.

The goal is to make everyone's life easier ^^

[valeriocomo]

@geromegrignon thank you for this update. It would be great to get involved, whether now or in the future

[geromegrignon]

@valeriocomo considering using this workflow from Transloco fyi https://github.com/jsverse/transloco/blob/master/.github/workflows/release.yml

[geromegrignon]

@valeriocomo if you want to get involved now, we can give a try at using this GitHub Actions: you can create a PR for it.
it might need some changes to adapt to this repo.

[valeriocomo]

@geromegrignon I'll study it in the afternoon. I'll be back with an answer (PR or question)

[valeriocomo]

hi @geromegrignon. I've just opened a draft PR for the release, realizing that there was already a PR about it. It follows transloco release workflow. Check it out please