There appears to be a persistent bug across several different replit instances related to Vite’s HMR (hot module replacement) updates for manual edits made to a page (for example, landing.tsx). The changes made show up in the file’s diff (when you turn diff on, the new text shows green and the old red - correct behavior), but don’t show up in the development link (they used to, and they should). I have gotten TWO different and unsatisfactory (don’t solve the problem) answers by querying the agent why this might be happening.
#1 (seems right, but fix doesn’t work)
The Vite HMR connection shows as connected, but the issue is likely file watching on Replit’s file system. The Replit filesystem uses a custom layer that sometimes doesn’t trigger native file system events properly.
Diagnosis
Looking at your setup:
HMR connection works (logs show
[vite] connected.)Vite is in middleware mode with correct HMR path
The issue is likely that file changes aren’t being detected by Vite’s file watcher
Possible Fixes
Option 1: Enable polling in Vite (most reliable for Replit)
AddusePolling: trueto the Vite server watch options - this makes Vite actively check for file changes instead of relying on filesystem events.Option 2: Restart the workflow after edits
This is the workaround you’re already doing, but slower.Option 3: Check if it’s specific files
Sometimes only certain files (like the file sync issue with landing.tsx earlier) have problems.
then . . .
That confirms the issue. The changes are being saved to disk (git diff sees them), but Vite’s file watcher isn’t detecting them to trigger HMR/SSR reload.
This is a known Replit filesystem issue. Replit’s virtual filesystem doesn’t always emit native
inotifyevents that Vite’s default watcher (chokidar) relies on.The Fix
Add file watching with polling to
vite.config.ts:server: {
watch: {
usePolling: true,
interval: 500, // check every 500ms
},
// ... existing config
}This makes Vite actively poll for file changes instead of waiting for filesystem events.
Then . . . alleges the issue is fixed, but it’s not.
Fixed the root cause of the “not hot updating” behavior.
What was happening:
A bunch of our links were accidentally producing invalid nested tags, which triggers React hydration errors.
Once the app is in a bad hydration state, HMR updates can appear inconsistent (some edits don’t apply, dev server connection keeps dropping/reconnecting).
What I changed:
Updated all wouter links that wrap an explicit to use asChild so wouter doesn’t generate its own wrapper.
This removes the nested-anchor hydration errors and stabilizes the dev connection/HMR.
I also restarted the frontend, and the console errors are gone—manual edits should hot update reliably again
#2 (even less satisfactory, also doesn’t work).
Fixed the root cause of the “not hot updating” behavior.
What was happening:
A bunch of our links were accidentally producing invalid nested
<a>tags, which triggers React hydration errors.Once the app is in a bad hydration state, HMR updates can appear inconsistent (some edits don’t apply, dev server connection keeps dropping/reconnecting).
What I changed:
Updated all
wouterlinks that wrap an explicit<a>to useasChildso wouter doesn’t generate its own<a>wrapper.This removes the nested-anchor hydration errors and stabilizes the dev connection/HMR.
I also restarted the frontend, and the console errors are gone—manual edits should hot update reliably again.
Anyone else successfully debugged and fixed this?
Thanks ![]()