Module not found: Error: Can't resolve 'fs' halts StackBlitz bootstrap

The short answer

Module not found: Error: Can't resolve 'fs' is a compile-time module-resolution failure, not a runtime performance problem. StackBlitz browser projects bundle with webpack 5, which no longer ships automatic polyfills for Node core modules. The build aborts before any of your code executes, so no console.time output exists to measure — anything your profiler reports around this failure describes the broken build, not your application.

Fastest unblocking fix: remove the fs import, or tell webpack the module is intentionally absent:

// webpack config override (e.g. via a custom config in your StackBlitz project)
module.exports = {
  resolve: {
    fallback: { fs: false }
  }
};

Then guard every code path that touches fs, because the bundler will now succeed but an unguarded call still throws at runtime:

const isNode = typeof process !== 'undefined' && process.versions?.node;
if (isNode) {
  // Node-only logic here
}

Why this happens (likely explanation vs. confirmed behavior)

Confirmed, well-established behavior:

• Webpack 5 removed the automatic Node core polyfills that webpack ≤4 silently bundled. Importing fs in a browser-targeted build is now a hard error by design.
• Module resolution happens at build time. A failed resolve means the bundle is never emitted, so bootstrap — and all instrumentation inside it — never runs.

Likely, but verify for your project: StackBlitz runs two different engines. Browser-only projects have no Node runtime at all. WebContainers-based projects boot a real Node environment in the browser, where fs works in server-side code. Check whether your project starts a Node server; if it does, the right fix is moving the fs logic server-side rather than polyfilling anything.

Detecting the error early, before profiling

1. Run the production build (or at least the bundler step) in CI before any profiling session. A failed build is a gate, not a data point.
2. Lint for Node core imports in browser-targeted code — e.g. an ESLint import rule or a simple grep for from 'fs', require('path') in files under your browser entry point.
3. Treat "app never rendered" as a build-failure signal first. Check the build log before trusting any timing captured around it.

Polyfill or refactor?

Polyfills such as browserify-fs or memfs emulate the filesystem in memory or IndexedDB. Two cautions:

• Semantics change. In-memory "disk" I/O has completely different timing characteristics than a real filesystem, so instrumentation of polyfilled calls measures the shim, not your production behavior. This directly undermines your goal of pre-refactor profiling.
• Overhead is real but unquantified here. Bundle-size and runtime cost vary by implementation and by which APIs you touch. Measure with your own bundle analyzer and a targeted timing of the affected path rather than assuming it is negligible — or severe.

The cleaner long-term fix is isolating Node-dependent logic behind an interface and swapping implementations per environment (dependency injection or conditional exports), so the browser bundle never resolves fs at all. For pure prototyping, resolve.fallback: { fs: false } plus environment guards is the lowest-effort path that keeps instrumentation honest.

Verification checklist

1. Reproduce minimally: fresh StackBlitz project, add import fs from 'fs', confirm the build fails before app code runs.
2. Apply the fallback or remove the import; confirm the build completes and console.time now reports timings.
3. If polyfilling, diff production bundle size and time the affected code path with and without the polyfill.
4. Confirm which StackBlitz engine your project uses before choosing between polyfill and server-side extraction.

One open detail that could change this recommendation: whether your StackBlitz project is WebContainers-based. If it is, share whether the fs usage can move into the server process — that would make polyfilling unnecessary entirely.