No worries, I don’t take it personally. Also, I don’t think it’s necessary to mention that disagreeing with something is personal. We can discuss it. Opinions are welcome.
I partially agree with this. That’s why I mentioned that we are partially shifting our focus back to Rspack issues. We have been doing this since its initial beta about a year ago.
I don’t fully agree that we should give it 100% of our focus, though, especially since the number of Rspack reports dropped a lot months ago after the beta period. But I would say our focus can now be at least 50% as we validate reproducible issues and features ahead, like Rspack 2.0, that users would like to have.
Change Streams have had their own history of being pushed forward. Also, with OPLOG being considered by MongoDB as an internal API they may cut, moving away from it has been a requirement for a long time. The feedback on 3.5 has been really positive, with runtime performance contributions and extra development from many community members. So the fuzz and disccusion is not only about complaints, it’s also about excitement around positive efforts.
CapacitorJS has similarly been requested for years. You can look for it in forum posts. It was asked for continuously, even when the modern build stack was the main focus. Besides that, it’s known that CordovaJS being unmaintained is going to become a problem really soon. For example, some plugins like RevenueCat’s Cordova plugin will drop support in August 31th 2026, really close date. This is a plugin used beyond fun projects and critically needed in production apps. This is just one example of how we should keep a wide focus and apply our efforts across areas.
There has also been a lot of private and direct communication over the years asking for these things. With this, I want to express how important it is to give weight to each area we want to improve, and to have a healthy space and time to work on them.
So I agree that Rspack needs attention, and it is getting a large percentage of our time these days to prepare the fix and deliver them on next patches or feature releases. That will continue because of the latest reports and the excitement around Rspack 2.0. At the same time, other areas of Meteor also deserve thoughtful and transversal time and focus, considering other angles from users who need them.
Thanks for this report. We have had issues with memory. Many of them are solved on our side on meteor 3.4.1, while others rely on Rspack itself. I expect these issues to happen in tools, as there are still humans behind the development, not fully AI agents.
The good thing is that the people on the Rspack side are also aware of the memory issues they have, especially on large projects and with persistent cache enabled, which Meteor uses. Rspack 2.0 is about to deliver those improvements, so our focus moved to prepare Rspack 2.0 which is ready for next Meteor 3.6 release. I’m not sure yet if that will be the case for you. I will check whether disabling the persistent cache in your reproduction helps, so we can discard whether it is a Meteor-side problem.
I will also research your report more deeply in the following days. Keep them coming, since our efforts and focus will continue on improving the Rspack experience.