hi there… we’re using Cursor… one issue, is that Cursor likes to change a files quickly - ge change/fix/change/fix. This causes tons of local meteor rebuilds / excessive hot reload… which absolutely smashes the local machine.
What’s the best approach here? Should I be using METEOR_DISABLE_OPTIMISTIC_CACHING=1?
Any other thoughts/recommendations pls?
This env var is for production builds/deploys not for HMR. If you wanted to disable HMR you need to comment out (or remove) this meteor package hot-module-replacement in your packages file.
In Webstorm I have an option to control how AI assist does things. In Chat I get the answer and apply them myself or copy-paste and with the AI agent for coding (Junie) I have this Brave option to let it do the changes without my intervention.
Do you have similar options in Cursor?
Another thing, you might be able to add to the AI configuration and add something like update the files but do not save. It is the saving (at least in Westorm) when the HMR kicks in.
oh wait… I see Environment Variables | Docs is only for production this issue related to development only
Thanks Paul,
Also, not only is the setting different… but I just noticed Environment Variables | Docs is only for production and this is a dev issue.
Actually I will try removing the package hot-module-replacement thanks.
Update: mmm… I don’t have hot-module-replacement in my package file… .is it on by default? is there another way to disable?
A Meteor package not an NPM one. You find it in your_app/.meteor/packages
yep… .I looked in there, it’s not there.
update: this proj has been going a while 
upgraded from Meteor v 1 → 2 ->3
I understand the HMR is done by Curson and not by Meteor.
“Disable Auto-Apply of Changes: Cursor AI IDE tends to auto-apply code changes without confirmation, which can be frustrating. Although there’s no explicit official toggle mentioned, some users report seeking options to disable this auto-apply behavior in Cursor’s settings or preferences. If you find such a setting, turning it off should make the AI wait for your confirmation before applying changes”
“Workarounds in Other Environments (like Visual Studio): For hot reload in Visual Studio, users can disable automatic rebuild on hot reload and choose to trigger it manually. This behavior may have parallels in Cursor, but direct config specifics are less documented”
Isn’t it better to stop the app, apply AI, then restart the apps to see the changes? What justifies having the app started and see intermediate changes on the app from continuous AI updates?
Alternatively, switch the watcher to polling and increase the interval by setting METEOR_WATCH_FORCE_POLLING and METEOR_WATCH_POLLING_INTERVAL_MS. These variables work in Meteor 3.3 with the new watcher and in the legacy watcher. But you get a downgrade on the watcher when you truly need reload speed.
Thanks.
yep, that’s what I have been doing - but a real pain, slows down dev… in short when you’re using a tool like Cursor you want to be able to mix AI and human in the loop… .having to stop/start the Meteor server is not what I’d call an optimal experience
We’re on 3.3… can you please explain those 2 params a bit more… ie what settings /interval would I want?
Working with it now for a few weeks and it’s a real thing. Workflow would be really improved if there would be something that handles this in a better way. Unsure about the solution though.
There are real advantages to be achieved here in how effective you can put Meteor in use to develop real solutions.
A fast machine actually solves a lot of this btw, it helps a lot but I think a lot of compute power is lost because of the constant restarts.
Isn’t it better to stop the app, apply AI, then restart the apps to see the changes? What justifies having the app started and see intermediate changes on the app from continuous AI updates?
It’s really the combo of the Meteor reload with ai which makes this interesting. It allows for really quick iterations on for example a screen with a React app. You talk while looking at the results, it’s constantly going back and forth.
This was already a unique Meteor feature which worked great while coding by hand. Now it becomes even more interesting because it just goes way faster.
Not to toot my own library or anything. But to toot it anyway. Meteor-Vite handles file changes like this asynchronously, without the need to rebuild or restart the current server process.
Changed modules are sent over the wire and re-evaluated within a virtualized module context. Essentially brings the same HMR you come to expect when developing a front-end app, but for both the client and server. 
Limitation being anything that ties into Meteor’s core build system. For example when developing an Atmosphere package or making modifications to a local Meteor package. Apart from that, application code and anything managed by npm or Node’s native module system is handled at lightning speeds 
So the AI can make a bunch of change in seconds … .what it would take a human to make in several to tens of minutes.
What would be nice:
@nachocodoner still would like some more details on those params please Any one using Cursor (AI editor) with Meteor? Hot Reload dramas - #9 by adamginsburg
@paulishca Personally I don’t to stop the auto apply, I want to be able to easily review the changes Cursor (got changes) is making (needs a human in the loop vetting the changes), so they need to be saved by Cursor.
BTW, I don’t see “hot-module-replacement” in my .meteor/packages. I do see a hot-code-push in the .meteor/versions
We’re on 3.3… can you please explain those 2 params a bit more… ie what settings /interval would I want?
These are just env variables. Use them as shown in the docs link above when running meteor run. I can’t say what exact values you’ll need, you’ll have to experiment to see what fits your setup. Keep in mind though: increasing the watcher interval won’t make updates show up faster. METEOR_WATCH_POLLING_INTERVAL_MS basically adds a debounce so file changes trigger only once per interval. That reduces load on Meteor’s core, but it won’t make reloads more responsive, and might even delay them.
Limitation being anything that ties into Meteor’s core build system. For example when developing an Atmosphere package or making modifications to a local Meteor package. Apart from that, application code and anything managed by npm or Node’s native module system is handled at lightning speeds
I think @jorgenvatle summed that up well. Meteor’s current bundler doesn’t handle reloads efficiently. Using a modern bundler like Meteor-Vite makes reloads much quicker, with faster rebuilds, HMR and no full server restarts frequently. All this happens by offloading app code compilation to a modern tool. Maybe try Meteor-Vite as a proof of concept and see how it performs for you.
Officially, we’re addressing this with Meteor-Rspack integration. Reloads there are much faster and less resource-heavy, which should improve the AI-driven code change workflow once that milestone lands. That’s our short-term path forward with modern tools. We’ll come back to this after the 3.4 beta is out so you can test it and share feedback.
Cool will wait for that!
Thanks - looking forward to that
