react-fast-refresh meteor package works great, instantly updates.
But then about 3 seconds later the node terminal running the dev server shows: client modified -- refreshing
And then it reboots the entire system and reloads the page.
Which negates the entire point.
I’ve tried disabling with this Reload._onMigrate(() => { return [false]; });
and this Reload._onMigrate('LiveUpdate', () => { return [false]; });
But neither seem to change anything about the “client modified” resultant.
Anyone know what to do to stop meteor from rebuilding the entire app and rebooting it everytime you change a jsx file(located in the imports/ folder) during development?
It is difficult to debug HMR issues. If you can create a reproduction, it would be much easier to look into what is happening. I’ve been planning to add a feature to HMR to log why it is unable to apply an update and has to reload the page, but it is a low priority so it probably won’t be added soon.
Alternatively, sharing the code from the file you modified might also help with identifying why it isn’t working. Also, there might be problems using React 18 - we need to update the react-refresh in Meteor to fully support it.
If I remember correctly, HMR forces Reload to reload the page when it is not successful in applying the update with HMR. With HMR, changes are applied in two stages:
First there are eager updates. These happen during the build process as parts of the app are built
After the build finishes, and the server restarts if it was a full rebuild, it gets the full list of changes that happened during the build. It applies any changes missed from eager updates, checks if there were any types of changes that could not be applied with HMR or if any of the eager updates failed. If necessary, it reloads the page.
Thank you both!
Tried removing react-fast-refresh, said wasn’t an added package. Found that it stems as a dependency of ecmascript package (thus I cannot remove). Not positive precisely how that all comingles in with the HMR package but it must be
Spun up a project from scratch to reduce into a reproduction for evaluation.
Started with meteor create test-app --react
Tested valid, altering jsx does not cause the situation on a fresh install with react v17.x and meteor v2.8.0
I still see the client modified -- refreshing, however it does not recycle the entire system nor refresh the page.
I then added all the meteor packages I used in my old project (+10), without any changes to code.
Notably:
tracker
reload
dynamic-import
ddp
Tested again and same outcome – no issue.
So that leaves the code itself as the root cause.
Started with dynamic imports. Tested good.
Added DDP. Tested good.
Added some of my boilerplate from the core of other project (session, subscriptions, useTracker(), etc etc)… Still tested good.
Color me baffled.
Then realized the only difference is that one project (the big one) takes a long time to recompile (25 to 60 seconds), whereas the new sample project takes a couple seconds.
So what appears to be happening is that when HMR pushes the file (client console says: HMR: updated 1 file), the node op server-side seems to be repackaging the bundles (recompiling but not rebooting the server).
aka Client modified -- refreshing
And that process takes so long, that DDP disconnects.
And when it reconnects, sometimes it appears to cause a page reload – but not always.
Thinking what you said regarding the failure to update may be the case here.
Perhaps it’s waiting for the client to indicate successful HMR push? And it takes too long and times out?
I see no issue or fault here on the Meteor side, not really.
I just need to reduce my node_modules footprint by a factor of 10… somehow.
And rethink my react tree computational dependencies, to avoid the excessive render cycles (useTracker() on DDP.DDPStatus and Session.get()).
But I love your idea of better logging deeper into that HMR push cycle; that would at least tell us what is going on under the hood.