Module not found: Can't resolve 'fs'

// ✅ Next.js — fs runs on the server only
export async function getServerSideProps() {
  const fs = await import('node:fs/promises');
  const data = await fs.readFile('data.json', 'utf8');
  return { props: { data } };
}

What you're seeing

Module not found: Can't resolve 'fs'

Import trace for requested module:
./lib/read-config.js
./components/Sidebar.jsx     <-- a client component pulled in server-only code
./app/page.jsx

Follow the "Import trace". It shows the chain from a browser file down to the module that imports fs. The fix goes at the point where client code first imports something server-only.

Fix 1 — Keep fs in server-only code

When: your own component or util reads files and also renders in the browser.

// ❌ a Client Component importing fs
'use client';
import fs from 'node:fs';         // bundled for the browser -> Can't resolve 'fs'

// ✅ read on the server, pass data down as props/args
// app/page.jsx (Server Component — no 'use client')
import fs from 'node:fs/promises';
export default async function Page() {
  const cfg = JSON.parse(await fs.readFile('config.json', 'utf8'));
  return <Sidebar config={cfg} />;   // Sidebar is the client part, no fs
}

In the App Router, files are Server Components by default — fs is fine there. The moment a file has 'use client', it (and everything it imports) is bundled for the browser, where fs doesn't exist.

Fix 2 — Split a shared module

When: one util file exports both a file-reading helper and something the client needs.

// lib/config.server.js   — server only, may use fs
import fs from 'node:fs/promises';
export const loadConfig = () => fs.readFile('config.json', 'utf8');

// lib/config.shared.js   — safe for the browser, no Node built-ins
export const DEFAULTS = { theme: 'light' };

Bundlers pull in the whole file you import from. If the client only needs DEFAULTS, keep it in a file that never touches fs so the server-only half is never dragged into the client bundle. (A .server.js/server-only convention makes the boundary obvious.)

Fix 3 — Dynamically import a Node-only dependency

When: a package uses fs internally and you only call it on the server.

// only loaded when this server path runs — excluded from the client bundle
export async function POST(req) {
  const { parseFile } = await import('some-node-only-lib');
  return Response.json(await parseFile('/tmp/x'));
}

A top-level import is always bundled; a dynamic await import() inside a server-only function keeps the Node dependency out of the browser build entirely.

Fix 4 — Stub fs in the client build (last resort)

When: a dependency references fs but the code path never runs in the browser, and you can't change it.

// next.config.js
module.exports = {
  webpack: (config, { isServer }) => {
    if (!isServer) config.resolve.fallback = { ...config.resolve.fallback, fs: false };
    return config;
  },
};

fs: false replaces fs with an empty module in the client build. This only silences the error — if that code actually executes in the browser it will still break at runtime. Use it only when the fs path is truly dead on the client.

Fix 5 — Vite specifics

When: the same error under Vite (which only targets the browser).

// keep fs in an SSR entry / API route / node script, never client code.
// for an SSR-only dependency, mark it external so it isn't bundled:
// vite.config.js
export default {
  ssr: { external: ['some-node-only-lib'] },
};

Why this happens

fs, along with path, crypto, net, and child_process, is a Node.js built-in — it only exists in a Node runtime. A bundler building for the browser has to resolve every import to something it can ship, and there is no browser fs to resolve to, so it stops with Can't resolve 'fs'. The import itself isn't the bug; the bug is that a module which uses a server-only API got pulled into a client bundle. That happens when server code is imported (directly or transitively) by a Client Component, a browser entry, or a shared file. Fixing it always means re-drawing the server/client boundary so fs stays on the server — not installing a package.

By tool