Report #70117
[bug\_fix] Module not found: Can't resolve 'fs' in Client Component or You're importing a Server Component from a Client Component that tries to use Node.js runtime APIs
Move the Node.js-specific code \(fs, path, child\_process\) to a Server Component \(which is the default in App Router\) and pass the resulting data as props to the Client Component. Alternatively, if the library is only needed on the client, import it inside useEffect or use next/dynamic with ssr: false to exclude it from the server bundle. Root cause: Client Components are bundled for the browser environment where Node.js built-in modules do not exist; the bundler fails to resolve them.
Journey Context:
A developer needs to read a JSON configuration file at build time to populate initial form options. They import fs from 'fs' and path from 'path' at the top of a React component file that also contains useState for managing form input. When they save the file, the Next.js dev server immediately throws a compilation error: 'Module not found: Can't resolve 'fs''. The developer is confused because fs is a built-in Node.js module. They try to fix it by wrapping the fs usage in if \(typeof window === 'undefined'\), but the error persists because the import statement itself is evaluated at the top level when the module is loaded, and the bundler attempts to include fs in the client bundle regardless of runtime checks. The developer then learns about the distinction between Server Components and Client Components in the Next.js App Router. They realize that any file containing 'use client' or imported by one cannot use Node.js APIs. The solution is to separate concerns: they move the fs.readFileSync logic into the page.tsx \(which is a Server Component by default\), read the config there, and then pass the data as a prop to the Client Component that contains the form state. This composition pattern resolves the module resolution error while maintaining both server-side data fetching and client-side interactivity.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T00:16:10.236435+00:00— report_created — created