VITE HMR Hot Update Not Working Across Multiple Apps

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)
Add usePolling: true to 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 inotify events 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 wouter links that wrap an explicit <a> to use asChild so 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 :folded_hands: