nx-remotecache-custom
nx-remotecache-custom copied to clipboard
NiklasPor
Future of nx-remotecache-custom with Nx 20+ changes
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:
- Creating a custom executor wrapper that could interact with Nx's new caching system
- 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.
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: https://github.com/nrwl/nx/issues/28150
@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.
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
As you stated at v21 and up, does that infer that there will be a v20 supported version? @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 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 š
Looks like he's responded https://github.com/nrwl/nx/issues/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
@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
Seems like there will be a free self-hosted version for custom caching: https://github.com/nrwl/nx/issues/28434#issuecomment-2683525056. Might be interesting for everyone following this thread.
Seems like there are two options now:
- migrate our custom runners to the new API: https://nx.dev/deprecated/custom-tasks-runner#the-pretasksexecution-and-posttasksexecution-hooks
- use @nx/s3, @nx/gcp, @nx/azure and related packages which are now free for everyone but do require activation
see https://nx.dev/blog/custom-runners-and-self-hosted-caching
I'd prefer to continue to use custom caches based on the new API's, rather than being beholden to Nx and their activation keys which would very likely require an active internet connection.
But since I'm in no position to actually migrate nx-remotecache-custom from a custom task runner to an API-compliant remote-caches (I simply lack the skills)... I really hope that this isn't the end for this project ;)
I created a lightweight custom Nx cache server written in Rust. So I just wanna share a link with you here. It's private. Zero telemetry. https://github.com/nxcite/nx-cache-server
