Migrating Nx core to Rust & deprecating custom runners #28434
Comments
With regard to this, I would have helped add support for Bun into Nx's own task runner, but at the time Bun didn't support half the modules Nx uses and would only work with web workers over IPC. I did actually provide feedback to the Nx team as there were some benefits over IPC. I want to express my disappointment that Nx has refused to consider opening up remote caching in Rust. All competitors have either opened up this ability or are working on it.
While I respect that Nx has venture capital to consider and needs a return on investment, and that this is Nrwl's business, I believe most enterprises would still pay for Powerpack. However, smaller teams and indie developers would much prefer to host their own. Personally, I have privacy concerns with any cloud—no offence—and would much prefer to control it myself. Taking away a functionality that you admitted was used by the community and putting it behind a paywall is disheartening. Regarding Powerpack, I find the pricing confusing, particularly in terms of how many seats are required. Does each developer need a seat to use Powerpack? Have you considered selling sections of Powerpack independently and adjusting the pricing for small teams? edit: I don't like this but i'm forking NX core to consistently add API first in the JS and then into the rust to ensure community solutions can still work. I think disingenuous to call this and focus so much on task runner when this move actually remove NX support for free custom cache. Again love you guy and women but please rethink and allow the API to be open at all point not eventually. |
|
Is it planned to expose an API to add custom remote caching in the Rust implementation ? |
Sorry not to keep hating but that comment feels belittling. I'm sorry you made this amazing tool. Caching was extremely useful before but we have limited funds as we not backed by VC yet. Please give me charity. honestly thats how it reads |
|
Shared cache Is also necessary to reuse cache between pipeline runs in a stateless build cluster like kubernetes or will there be another option to achieve this? From my understanding, without Powerpack or NX Cloud it will not be possible to have "Smart Monorepos AND fast CI" if you dont have a stateful CI executor, but thats something that NX wanted to provide, isnt it? If you allow a suggestion, you may put features like special/ complicated executors or plugins for e.g. Cmake, Conan or other C/C++ stuff in a powepack, but not core features. I mean 20% faster sounds great at first, but compared to what? Typical build/test task might take some minutes, it does not really matter if it takes 100ms or 80ms to load it from cache instead. |
|
So if i TL;DR; this, it can be summed up to: That's legitimate, but know that one of the main reasons we choose Nx is for that specific reason. And we are now forced to evaluate other options if they turn up to be cheaper or more flexible. And my 2 cents about typescript -> rust migration. I as a consumer of Nx will greatly appreciate an extensive, robust and well documented programmatic API for Nx rather than any rust re-write and small speed improvement. Nx is mostly IO bound (except for the caching stuff that needs to hash, read and parse and write a ton of files) can't you just make parts of Nx in rust? like the caching mechanism? At this point i feel that Rewrite It In Rust™️ is more of a marketing strategy rather than a practical engineering consideration. Sorry for all the 🌶 takes - i say this as a long time avid NX user. |
|
In my current job we have a team of 20 developers working on a massive monorepo with NX as the underlying framework. We chose NX specifically for its free tier features including on prem caching as security is paramount to our organization. We use on prem minio s3 storage that we control and administer ourselves. I was surprised to learn this week by means of a warning when run
To learn such an important update from a random warning is really poor communication from NX. I had a look at site for activating powerpack and with the amount of developers working on our project the total comes up to $495.00 A 20% speed increase in a command starting up is nothing in comparison to the speed increase that remote caching offers. Unfortunatly NX has now lost credibility within our organization, reason being, if you can randomly put caching behind a paywall what's to stop NX from putting other features behind a paywall?
We have already started planning for migrating off of NX and are looking into turbo repo as we are not happy with essentially being held to ransom for trusting NX. I should note that personally I was a massive fan of NX, I was the one who incorporated it into our development process and honestly it has been an amazing journey. I even wrote an article about it here - https://medium.com/better-programming/migrating-an-angular-application-to-module-federation-with-nx-74f7664bab3e?source=your_stories_page------------------------------------- Thank you for all the work up until now, but if this change goes ahead we will be moving on and I suspect a lot of others will also |
100% agree, I've stopped making NX a priority for client. I'll be recommending other tools as well going forward. NX to me now has zero credibility. I also found this quiet disingenuous too around codeowner.
He went on to create a community plugin npm i @swapniltech0390/nx-codeowners https://www.npmjs.com/package/@swapniltech0390/nx-codeowners |
|
The custom NX license states:
However, much of this appears to be documented and available under the MIT version of the code. How is this license valid if the API/know-how for producing related software comes from the MIT version? Does this mean any indie hacker using APIs provided by the MIT or any tweaks to the MIT code to open up would be a breach. |
|
I'm going to post this from an anonymous account because our threads and phone calls should not be about this. The deprecation that prompted this series of threads Nx Powerpack offers a JSON-to-CODEOWNERS converter, an ESLint rule, and cache self-hosting which was previously available but not marketed. Assuming an organization with 30 developers, that's almost triple the price if you want to use your own cache and if you gave up on agents, dashboards, and log viz. I understand these are two completely different products aimed at different target groups but as an engineer I can't help but compare the amount of effort that has gone in one vs. the other and the two are not close. And the way these are perceived informs whether engineers would recommend and implement Nx in their organization. Unclear terminology in sales pages Unclear licensing Removing previously available functionality Comparison with competing products Public communication: correctness and timeliness Timeliness is another thing. The post is dated Sep 25th and its follow-up explanation is dated Oct 14th. Public communication: subjective interpretation
This is great, except that now Nx now has a history of removing core features. This reads as "we can help you adopt Nx but you'll have to hope we won't change the terms again".
This is only "technically correct" as evident by the recent issues and PRs getting created around this. Nx is offering a product to developers. Nx is taking away building blocks from developers. Nx now has to somehow convince their main audience that this is a good thing. My team is prototyping micro frontends via module federation and NX in our company and we are potentially exploring the enterprise version of Nx. Our frontend team has always been lean so this wouldn't be a hard sell, nor it would be my money - but the actions and the communication of Nx around this are very encouraging to look for alterntaives. |
We have our own implementation of the Powerpack features for some time now, with our own implementations:
Here’s the issue: Removing the custom runner API directly eliminates a previously free feature (custom remote caching). Forcing us into a subscription for this capability effectively moves it behind a paywall. What’s next? Will other key Nx APIs be removed, forcing users to subscribe just to maintain custom conformance or codeowners management? This approach erode trust with your community and undermines the value that Nx provided by being open and extensible. |
|
heh I was looking into NX, but the lack of self-hosted caching without having to pay for an enterprise license is a no-go. I found this thread by looking into alternatives. NX Cloud sounds good enough, but even if we decided to pay, just not having the option to do the remote caching in-house, and for free, is a huge blocker. |
|
I'm encourage by the new license thats been recently added This at least address concerns it felt like we need to beg for access. However their seem to be little documentation on what "restricted license " means compared to the unrestricted. @vsavkin is their a link or something we can read to see what the restriction is. Also could you address the concerns that the powerpack license seem to contradict the MIT license
This can be done via MIT code and looking at the code. Already using plugins that does codeowner etc. I'm personally using a patch for NX to allow remote caching (all without looking at powerpack code) does this mean that not allowed? |
|
looks to be very restrictive: |
Why i'm asking because it looks no different for me |
|
This is what I see |
|
You need to change the Number of developers |
|
Then it is not restricted at all 👍 |
|
I kinda feeling this has mainly been a badly managed release from a PR and communication point of view but if the above is right then its not perfect i think opening up cache should happen, but its a lot better than it was first presented
Which is why im asking for clarity |
|
Sorry for the delayed response, we're still catching up after Monorepo World. I won't repeat what Victor mentioned in his post, so please check that out first. However, I want to focus on a couple of things:
We're grateful for the feedback 🙏. It showed us that while we had mentioned it in a few places, we missed the mark and needed to be much more explicit in our support for smaller teams. We've now updated the Powerpack page and the license application process to make these points more clear:
If you're a small team and you rely on custom task runners for S3 caching, please contact us—we definitely don't want anyone feeling blocked by this. |
|
Thank you so much, Juri. Everyone, I apologize for my unclear communication. And I appreciate everyone's constructive feedback. My Twitter DMs are open to anyone who wants to talk in good faith. I'm also happy to jump on a call. I chatted with many folks last week and the week before; this remains my top priority. Nx is a small business with a few dozen engineers. We know how hard it is to run a small business, so we're offering all small businesses remote cache implementations for free. |
|
@Jordan-Hall That is my personal twitter account. The Nx account didn't block you. You declined my invitation to talk to you. After I texted with you in good faith, trying to be clear and honest, you published our private communication without my permission, which isn't acting in good faith imo. That's why I don't think I can trust you, and I decided not to engage with you on social personally. You are free to engage with other folks on the Nx core team though. I'd also like you to read through https://github.com/nrwl/nx/blob/master/CODE_OF_CONDUCT.md which is there to protect the wellbeing of all Nx contributors, regardless of their position. Further violations of the CoC will leave us with no choice but to restrict your access on GitHub in order to preserve a safe space for our community. If you want to restart the conversation constructively, I'm happy to have a VC with you. Thank you! |
I said it was something i didn't like because people seem to be in the dark. It was release as good faith so people know what it was about (not to make you look bad or in bad faith, sorry if you took it that way.. Im sorry @vsavkin, i like things open but sure would take a call now im actually feeling well enough. The new update looks great but seems confusing around "Free restricted license." I cant find documentation on the restrictions, |
What is considered a "small team" out of curiosity? |
|
Some folks have asked for clarification on what we mean by one license type being "restrictive" and the other "unrestrictive." To clarify, Nx Powerpack's self-hosted cache storage is free for small teams. See above. If you've been with us on this journey, used Nx, relied on self-hosted remote caching, and are part of a small team, we want to help you out. Our focus has been on building additional features that benefit our Enterprise users—like Conformance, Codeowners, and more to come—without impacting smaller teams of developers. We're not looking to impose extra costs on teams that are already bootstrapping their way forward. When we refer to a "restrictive" license, it means that free access is limited to the caching function, whereas "unrestrictive" licenses will include access to enterprise-focused features like Conformance, Codeowners, and others we develop in the future. What constitutes a small business is a company with dozens of software engineers or, in exceptional cases, small independent teams in much larger organizations. So far hundreds of companies have requested a small-business discount for Nx Cloud. All requests were approved. We have the same attitude towards Nx Powerpack. We will update the landing page to make the points clearer. Thank you for engaging with us, folks! |
It seems like those are great, net new powerpack features. But based on the feedback on this thread (sorry to pile on and rehash), I think everyone would be very happy to see self-hosted caching provided as free based on the OSS usage history here and pay for those new functions. Right now it's a bait and switch. And now I have to have a conversation amid cost cutting efforts along the lines of "Hey we need to pony up tens of thousands of dollars just so that thing I committed us to and said was free last year can keep doing excatly what it does"... I'm personally very excited to see where compliance goes. but I don't like being put in that position. It's disingenuous to include caching in: "No, we’re not placing existing features behind a paywall" We're not a small company, I don't feel legitimate amongst others here asking for a broad exception for powerpack (but I do for caching). I would go to bat and seek funding for these new features. But the money grab on caching needs to be acknowledged; there's no way around it. |
|
I know there's a real desire to avoid having a JavaScript runtime within Rust code due to performance and package size concerns. However, what about running WebAssembly or dynamically linking with a shared library? It would be great to create plugins without having to use JavaScript. This would be an ideal example to get it working without making it feel like a cash grab. I'm sure it's a good middle ground, ensuring flexibility while still meeting all your goals. |
|
@vsavkin @jeffbcross I think a big piece your team is missing is that for larger companies (like ours) we would be happy to pay for products that add value (which Nx does) but we need an off-ramp and this is what custom task runners/self-hosted caching provided—having these options available to us is a big part of why we chose to integrate with (and pay for) Nx. This change has turned your product into a one-way door and I can’t advocate investing in a product that we have no way of pulling out of if our needs change in the future. We try to avoid putting ourselves into a state of vendor lock-in. |
|
@jeffbcross @vsavkin is it possible to start having RFC for big changes, allow community to provide early feedback ans suggestions. I'm sure people would love to help out more and with a design for making this still work in rust |
|
You previously claimed that Powerpack was not replacing open-source features with paid subscriptions. However, this blog post change shows otherwise. We’ve now confirmed that functionality—like custom remote caching—has been moved behind a paywall. It would be fair for the Nx team to remove this limitation and allow the same API to remain accessible in the Rust implementation. If open-source features can simply be reclassified as premium, this sets a dangerous precedent. What’s stopping other Nx APIs from being locked behind future paywalls? This shift makes relying on Nx uncertain, as it suggests that any feature could be turned into a paid service at any time. |
|
While supporting OSS and small businesses is a noble and just cause you still haven't addressed the concern for big companies yet. We're a big company.
In either way we'll have to pay a large fee - either in buying the nx cloud service or by putting large amount of dev hours on finding another solution, or by giving it up to and eat the extra time remote caching saved us. In any case, this feel basically like ransom and is not a behavior i would expect from a company such as yours. This kind of behavior trashes the trust and reliability we have in Nx. |
|
I'd like to second @ItamarGronich's comment from a position of another non-small-business. I am currently investigating using Nx in our organisation. We see some huge benefits it could bring us as a business, but as with any new technology we have to go iteratively, starting from early adoption of the OSS, and then, if we prove the value, attempt to scale it further, considering commercial options like Powerpack or Nx Cloud. However before considering paying for anything I need to build trust in the tech and the team behind it, so that we don't find ourselves with vendor lock-in in the future. I also need to show the value of it before investing any company's money which I could possibly do using custom runners before (e.g. "hey, here's how we save money on CI bills and eng context switching by using custom cache, how about we buy Nx Cloud and save us the effort of maintaining homegrown solution while also having other huge benefits?"). Now we have a big problem both with trust and the ability to demonstrate the value. I am still an Nx enthusiast, and I believe that it has huge benefits, but this situation is a huge red flag for me. I haven't reported it back to my superiors yet as I believe that the pushback from community could somehow convince Nx team that their decision, though seeming profitable short-term, can cost them more long-term as trust would be eroded and potential customers who are ready to pay for something that brings them value would have to consider other alternatives, but I will have to do it, and the only answer that comes to mind is to scale back the adoption and consider moving to Turborepo (which was our second choice as it loses to Nx for a number of cases specific to our business). I appreciate your efforts to make Nx faster by jumping on the web-wide trend of rewriting to Rust, but I would appreciate even more if this decision was scaled back (and other such impactful decisions would be discussed with the community well in advance via RFCs of sorts) by providing some sort of API for those who would like to build their own caching solution (with a disclaimer of some sort "if you're using this, we'll have to run JS runtime in rust which will make your Nx core working slower", we understand the tradeoffs and we're ready to maintain some custom code for a while, because that's how big migrations in the current business environment work) |
|
We have been using Nx for over 4 years with our custom runner in all projects, after seeing the warning and trying to investigate what a Powerpack was came to this issue. In the past years we already had multiple annoyances of Nx doing things that broke everything for us and we had to spend hours upon hours to figure out what, we accepted this as Nx being Nx because we really liked the ecosystem and the extendability of it. That we now have to pay for something that has always been free is just absurd, even with the "free" licence, why? Why would we now suddeldy need to request and get approved for a license to use what we are/where already using for the last couple of years? My 2 cents about the migration from Typescript to Rust: Would rather see more focus on existing tickets/bugs that are now ignored (#22213, #26577) instead of rewriting the core into Rust to improve performance of something that, in my opinion, is not slow. |
|
@juristr with this now being closes can we assumed its all going ahead as planned and this should be closes? |
|
Yes, I don't see any meaningful response from the Nx team on the concerns raised throughout this thread. It would be helpful to understand their approach to these issues, especially to reassure the community about the future direction of Nx. Even if no changes are planned, we still deserve a clear and direct answer. The current silence only adds to the uncertainty. If APIs and extension points are being removed or moved behind paywalls, users need to know now, so they can make informed decisions about whether Nx will continue to meet their needs or if they should start exploring alternatives. Transparency is key to maintaining trust in the open source community. |
|
Time to start taking NX out of everything |
We too use on prem minio storage and would not like to see this changed. It makes sense to pay for the features that NX provides as a service, but for us to pay for using a shared fs cache to setup ourselves as well... What is that about? We've been (and myself personall) very happy with NX all through the years, but changes like this makes me rethink what the direction of the whole organisation is moving forward. As others have stated, what will be the next paywall? |
|
Thank you for engaging with us! Anyone who has spoken with us in person at conferences knows that the Nx team, myself included, is always happy to discuss what's in progress and what's coming next. However, we want to do a much better job of sharing this in a more public way, so everyone interested can stay informed and have an opportunity to share feedback early on. To achieve this, we're making a few changes:
I'm personally committed to engaging with the community. If you have questions or concerns, feel free to DM me on Twitter, and I'll be happy to have a video call with you. You can also engage with Juri in the same fashion. Discord is also a great place to engage at. I'm sorry we didn't do a good enough job of communicating with the community. We are doing our best to address it. If you have any questions about these updates, please engage with us! |
This sounds great, but is it too late for the current approach regarding this issue? Or can you start again and rethink, or allow community input or idea on making a rust base plugin |
I think you've actually engaged with the community pretty well. It's the community that is stumped and in disbelief. As said in the opening post;
There should be little doubt about what that means. For many companies (especially outside of SF or US) the costs for your services are a significant expense for what is essentially some convenience. In comparison to all the free CI/CD and OS options available, this can be a tough expense to justify. Obviously; new kids are knocking at the doors. Drastic changes are necessary. But for those who have contributed to and enjoyed using NX, this feels like a free tool being hijacked by a commercial entity. Losing some of the community might not impact the bottom line, but without growth, the project/company's future is at risk. If growth only comes from imitating competitors, it’s a losing game; free and open-source alternatives will simply keep nibbling away. So far, I haven’t seen anything that goes beyond merely catching up. |
Just wanted to echo the sentiment in the post above by @johannesnormannjensen. We too have been using Nx for a few years (with varying degrees of satisfaction, but pretty happy with it for the most-part), and while I can understand a pay-to-play model for consumers who wish to utilize Nx's cloud-based infrastructure for caching/analytics/build process, etc., I'm hard-pressed to understand the logic behind hobbling the framework, and then requiring a paid-package to unhobble it, for those who have no ties to Nx cloud infrastructure. In our particular situation, we are fairly tightly-controlled with respect to data egress, and we use nx-remotecache-azure so that our cacheable assets never leave the confines of our corporate network. I've hemmed and hawed a bit about whether or not we'd just bite the bullet and "pay da man," but after fielding some bizarre build issues today that appear be related to #28599 and #28380, my confidence in the Nx tooling has taken a bit of a nose-dive. Properly sequenced builds within complex dependency chains is a core, if not -the- core, reason we chose Nx in the first place, and coming to find this broken - well ... let's just say that the corporate credit card swiftly moved back into safe confines of my wallet. And in continuing to emphasize @johannesnormannjensen's post above, as well as @Elyahou's similar point - what is the next thing that will become pay-to-play, even if we opt to forgo computational caching for now? The ability to make implicit dependencies between projects? Limits on the number of parallel task runners? Maximum number of projects in an Nx workspace? This approach does not seem like a sensible/logical "pay for what you use" model, but instead more of a "if we perceive you to be a big, evil, greedy corporation - we're going to work you like a mule" cash-grab. This kind of logic is made even more apparent by the attempt to assuage the angst in this thread by making self-hosted remote-caching with powerpack "free for small orgs." What difference does it make to Nx how big the org is if they're self-hosting their own cache? How does Nx define a "small org," and what will prevent that definition from changing tomorrow? There are pay-to-play models that would make more sense here, in my opinion:
Perhaps the time has come to start planning our move away from Nx. |
While the proposed changes are a step in the right direction, they don’t address the immediate issue: this decision was made without community input, and the feedback so far has been overwhelmingly negative, as shown in this issue...
These changes are planned for future versions of Nx, and since it’s unclear when the migration to Rust will happen, there’s still time to reconsider. Deprecating the API before Rust is fully implemented creates unnecessary friction. To show good faith and rebuild trust, this decision should be revisited with the community’s input. |
|
It is a shame I really like NX, but I guess they have to somehow get money from NX. I totally understand that but $25 per users per month is a very expensive price. Github copilot only cost like $20 for business and it provides more value. If we don't use nx cloud resource, I really can't justify $25 for a remote cache feature that actually using our own resource. I think it is probably impossible to ask NX team to change their mind on paying, but I think could you guys at least provide something cheaper for smaller teams like ppl < 100 or 50? I think docker's pricing is a good one update: I just tried to apply for the free license, it seems like we are qualified for it. I really appreciate it. |
|
Honestly, I understand why NX decided to put the remote cache feature behind a paywall. Building and maintaining NX takes a lot of time and resources. I just hope the NX team can find a sustainable way to keep moving forward. As an open-source developer, I recognize it’s unrealistic to expect everything for free indefinitely. I personally don’t charge for my open-source projects since it's a passion project for me. I even convinced my boss to let me support open-source contributions for the tools we use in our company as a small way to give back to the community. However, I believe there's a difference when people are working full-time to support these projects. Let's face it, if NX can't keep going forward, I think it is still a bad outcome for everyone. There are so many open source projects died already. I’m grateful that NX provides us with a free Power Pack since we’re a small team (under 15 people). 🙏 I hope the community can come together to find a balanced solution. |
|
Dear @vsavkin & @jeffbcross, Godspeed. |
|
This post did not age well https://www.linkedin.com/posts/zackderose_we-were-intentional-with-nx-to-allow-other-activity-7069448865090859008-vnLI _Zachary DeRose 💯 We were intentional with Nx to allow other task runners that implement their own distributed caching! But caching can be hard. Nx Cloud is the first-party solution here (checkout https://nx.app) and we're investing our engineering resources into making this an excellent experience for our users. Nx Cloud is free up to 300 CI runs a month (all non-CI runs are free) and there's a special unlimited tier for all open-source projects, and comes with some nice features like linkable task logs, Version Control System integrations for Github/GitLab/BitBucket, and support for Distributed Task Execution! You can try it now simply by running NX team must reconsider removing existing open source functionality they intentionally offered. The disruption you are causing existing teams using custom runners will likely cost more then the net revenue gained from placing it behind a pay wall. As an architect at a leading investment bank, having used NX for over 2 years in our project, out of principal there is no way we will consider signing up for Power Pack due to the questionable approach in which it was introduced. The LinkedIn post above from an NX core team member is partly why we felt comfortable using custom runners. Lies.... |
|
My CI/CD pipeline runs concurrent NX processes in the same workspace (e.g., build and lint). Starting with version 19.8.*, I've started seeing occasional SQLite errors, which suggests the metadata SQLite database might be corrupted by concurrent writes from multiple NX processes. Will this scenario (concurrent NX processes in the same workspace) be supported in future versions, or do I need to purchase the Powerpack to use the remote FS cache? |
|
We have a custom runner that calls our own API with security checks and authorization, which also have some checks for a cache before storing it to S3. So the developers don't have a real access to Amazon infrastructure and to S3 itself. Powerpack doesn't meet our needs in security and with restricted access to Amazon infrastructure. So basically with this change, we have only three options:
I don't think that this options are good. |
|
@ytchenak " My CI/CD pipeline runs concurrent NX processes in the same workspace (e.g., build and lint). Starting with version 19.8.*, I've started seeing occasional SQLite errors" It's a bug that should be fixed. If you upgrade to latest, the issue should go away. @alexhanga Could we set up a call to discuss your checks? Could you email [email protected], and I'll arrange a call? |
|
@o629625 Can we have a call to discuss your situation? If you email [email protected] we'll find a time to talk. |
@vsavkin, I’m glad to hear that there’s no additional cost for running concurrent jobs, but unfortunately, the issue persists even in the latest version (20.1.2). Please refer to this comment for more details: #28772 (comment). This issue is preventing us from upgrading to the latest NX versions. For now, I am forced to use the last NX version that does not rely on SQLite. |
|
Folks, I'd like to post a quick update on the process initiatives that should give a lot more visibility into the roadmap, how features are developed etc:
Let us know what we can do to tweak the process changes (especially the RFC) if they are useful or not. |
and others
UPDATE: Thank you for engaging with us. We took your feedback very seriously and clarified a few things. Most importantly, self-hosted remote caching provided by Nx Powerpack is free for small businesses and OSS projects. See here and here for more information.
We also added new ways of getting feedback and involve the community. See here.
Hi folks,
We are migrating Nx core from TypeScript to Rust, with a target completion date of 2025. The main reasons are to improve Nx's speed, reduce its package size, and enable a more powerful command-line interface.
While the rewrite to Rust brings many benefits, it also introduces some limitations, particularly with extensibility APIs. One example is the rarely-used API that allowed users to completely swap out Nx's task runner. While this offered theoretical "infinite" flexibility, it also meant Nx couldn't provide direct support for the use cases it enabled, leading us to discourage its use. In fact, we stopped generating any task runners properties in new Nx workspaces several years ago.
Despite the flexibility, very few concrete use cases for custom task runners emerged. The most common was larger teams wanting to use a self-hosted remote cache. Many such teams now use Nx Cloud (which starts free for small teams), but some still value the ability to choose their own solution.
To address this, we've introduced Nx Powerpack, which includes a dedicated solution for remote caching. Powerpack users can opt for our S3 or shared filesystem cache via new Nx plugins. If your team needs additional plugins for remote caching, please contact us at [email protected].
Another niche use of custom task runners was allowing Nx contributors to experiment with runtimes like Bun and Deno before they were officially supported. We encourage contributors to work with us directly to integrate such changes into Nx's open-source task runner.
We understand that this change would mean that some teams may need Nx Powerpack. While it's a premium product designed for professional teams, we know that every Nx user's situation is unique. We therefore have the following options available:
Finally, if you have specific use cases for custom task runners that we haven't covered, don't hesitate to open an issue.
Thank you,
Victor Savkin & Nx Core Team
The text was updated successfully, but these errors were encountered: