Future of nx-remotecache-custom with Nx 20+ changes

[abarghoud]

Hi,

With the upcoming changes in Nx 20+, particularly the deprecation of custom task runners and the introduction of Nx Powerpack for remote caching, I'm concerned about the future of nx-remotecache-custom.

Have you considered any potential workarounds or alternatives to keep this package functional with newer Nx versions? Some ideas that come to mind:

1. Creating a custom executor wrapper that could interact with Nx's new caching system
2. Implementing a CLI wrapper around Nx commands to handle custom caching logic

I think many users rely on this package for custom caching solutions. Any thoughts or plans you might have for adapting to these changes would be greatly appreciated.

Do not hesitate if I can help with any thing concerning this.

[NiklasPor]

Hey @abarghoud, thanks for your regards.

After looking into this I think it's very clear that Powerpack is supposed to replace nx-remotecache-custom as it has its own support for custom caching implementations.

From my perspective this will mark the end of this package, which is completely built around the task runners from Nx. I'm also personally relieved, because it's nearly impossible for me to allocate a fair amount of time to this project, while I'm working full time as a Co-Founder on LastBIM (a contech startup).

If you have any questions feel free to discuss here with me or the community. I also think there's a respective issue on the Nrwl Nx repository which goes into a similar direction: nrwl/nx#28150

[abarghoud]

@NiklasPor, thank you for your response. I completely understand the challenges of maintaining such a project alongside full-time commitments.

The shift towards paid solutions like Nx Powerpack raises concerns for users who rely on this "free" caching solution, particularly for smaller projects or those in early stages. This is why I am proposing these adaptation options, even if it's a significant undertaking.

If you're not planning to adapt the package for the new Nx versions, I could try to create a PR to implement some updates. If that doesn't align with your vision for the project, I’d be open to forking it to maintain a free option for the community.
Your insights and any advice you could offer would be very valuable if I proceed with a fork. Of course, I'd fully respect your decision either way.

Thank you again for your contributions to the Nx ecosystem and for considering this proposal.

[Jordan-Hall]

I'll post a full response soon but their multiple solutions to keep this going for now. Speaking to NX their issue is moving to rust and it will take time to reimplement the API

[EelcoLos]

As you stated at v21 and up, does that infer that there will be a v20 supported version? @NiklasPor

[NiklasPor]

@EelcoLos yes, as Nx 20 still has the same API available I'll publish a version for nx-remotecache-* once 20 is officially released

[EelcoLos]

@EelcoLos yes, as Nx 20 still has the same API available I'll publish a version for nx-remotecache-* once 20 is officially released

it just did this morning 😊

[NiklasPor]

Ah my bad, I always wait for my notification for the blog post 😂

[Jordan-Hall]

Looks like he's responded nrwl/nx#28434

I'm going to fork the NX core only to keep custom remote cache working and will make it work in rust too,Not sure if this is going to help

[Jordan-Hall]

@abarghoud would you accept a PR that helps enable it on the fork. It should make it easier as it same API as powerpack so doesnt require full task runner but will help allow others to integrate easier than figuring out the API