Rspack panic: “ModuleGraphModule … not found”

Real error I hit running npm start on this very career-sprint site.

[SUCCESS] Docusaurus website is running at: http://localhost:3000/
● Client ████████ (9%) setup compilation
Panic occurred at runtime. Please file an issue on GitHub ...
panicked at crates\rspack_core\src\module_graph\mod.rs:722:26:
ModuleGraphModule with identifier
Identifier("...\node_modules\@rspack\core\dist\cssExtractHmr.js") not found

The dev server started, then the compiler crashed mid-build at 9%.

What actually happened

This site uses @docusaurus/faster, which swaps Docusaurus’s default bundler (webpack) for Rspack — a much faster Rust-based bundler. Rspack keeps a persistent cache on disk at node_modules\.cache.

That cache had drifted out of sync with the freshly generated .docusaurus folder. Rspack’s cache “remembered” a module (cssExtractHmr.js) that the new build didn’t register the same way — so when it tried to look that module up in its graph, it wasn’t there, and Rust panicked instead of failing gracefully.

It’s a known Rspack bug, and it shows up most on Windows.

The vocabulary

Term	What it means
Bundler	The tool that compiles all your source files into what the browser loads. Webpack and Rspack are bundlers.
Rspack	A Rust rewrite of webpack — much faster. `@docusaurus/faster` enables it.
Persistent cache	Compiled results saved to disk (`node_modules\.cache`) so the next build is faster.
Module graph	The bundler’s internal map of “which file imports which.” The panic was a lookup miss in this map.
Panic	A Rust program crashing hard. The Node equivalent of an uncaught fatal error.

The fix — clear the caches and restart

npm run clear          # docusaurus clear: wipes .docusaurus, build/, and node_modules\.cache
# (npm run clear already removes the bundler cache; this is the whole fix)
npm start

Result:

client (Rspack 1.7.11) compiled successfully

Fixed on the first restart.

Why `npm run clear` is the reset button

docusaurus clear deletes three things:

.docusaurus/ — the generated site metadata/routes
build/ — the production output folder
node_modules\.cache — the bundler’s persistent cache (the actual culprit here)

Wiping all three forces a clean rebuild with no stale state to disagree with.

If it keeps coming back

This Rspack cache bug can recur on Windows. Two escalating options:

Quick: npm run clear + restart — the 10-second fix.
Permanent: drop @docusaurus/faster and fall back to the rock-stable webpack bundler. On a small site the speed difference is unnoticeable, and webpack doesn’t have this cache-panic bug.

The lesson

A “cache” is a speed optimization that assumes nothing important changed. When that assumption breaks, the cache becomes stale and causes errors that make no sense against your current code.
First move for any weird build/HMR error: clear the cache before debugging deeper. You’ll save hours chasing a bug that isn’t in your code.
“Faster” tooling (Rspack, SWC, esbuild, Turbopack) is newer and trades some maturity for speed. When it misbehaves, falling back to the proven tool (webpack) is a legitimate fix, not a defeat.

One-line summary

Rspack ModuleGraphModule ... not found panic = a stale node_modules\.cache out of sync with .docusaurus. Run npm run clear, then npm start. If it recurs often, drop @docusaurus/faster and use webpack.