StackBlitz Git rollback leaves preview stale after dependency change

The short answer

Yes — after a Git rollback, StackBlitz’s preview can keep serving bundles built from the pre‑rollback state. The most likely cause is that the rollback rewrites files outside the editor’s file‑watching path, so the dev server never receives a change event that would trigger a rebuild. In addition, the dependency install cache (node_modules) and the bundler’s module cache are not keyed to Git operations, so they stay stale until the user forces a reinstall or restart.

StackBlitz does not publicly document its cache‑invalidation behavior around Git operations in detail, and the exact behavior may vary with project type (Vite, Webpack, Angular CLI, etc.). Treat this explanation as the most probable cause, not a confirmed internal fact.

How to recover in this specific case

Because the rollback changed package.json, a simple browser refresh is not enough — the installed dependency graph itself is stale. Follow these steps in order:

1. In the StackBlitz terminal, reinstall the dependencies so node_modules matches the rolled‑back manifest:

   npm install

2. Stop the running dev‑server task and start it again so the bundler rebuilds from a clean module graph:

   npm run dev

3. If the preview still looks wrong, hard‑refresh the preview iframe or open the preview URL in a new tab to rule out browser‑level caching of the served bundle.

Verifying the diagnosis

You can confirm the missed‑invalidation hypothesis before changing anything:

• Check the terminal output. If the dev server logged no rebuild at the moment you performed the rollback, the file watcher never saw the Git reset — that confirms the preview is running the old bundle.
• Look for a source/preview mismatch. If the rolled‑back code removes a dependency and the editor now flags those imports as errors while the preview still runs fine, the preview is serving stale output.
• Isolate browser caching. Open the preview URL in an incognito window or append a cache‑busting query string. If the fresh context still shows the old behavior, the staleness is in the served bundle, not your browser cache.

Automatic reload vs. an explicit reset command

An automatic hard reload on every Git reset would guarantee consistency, but at a real cost: most rollbacks touch only source files, and forcing a full reinstall and rebuild each time would be slow and wasteful. That trade‑off is why platforms generally leave cache invalidation to the user rather than coupling it to VCS operations.

An explicit reset preview / restart server command is the better UX compromise. It makes invalidation intentional, avoids surprise multi‑second rebuilds after routine history operations, and gives users a deterministic recovery path when source and preview visibly diverge. Until such a command exists, the manual sequence above—reinstall, restart the dev server, then refresh—is the reliable equivalent.

If you can share which dev server the project uses (Vite, Webpack, Angular CLI, etc.), the answer can be narrowed further, as some servers persist their own pre‑bundle caches (for example Vite’s dependency pre‑bundling) that may need explicit clearing after a dependency‑graph change.