Module not found: Can't resolve 'fs in node_modules/destroy
See original GitHub issueBug report
After upgrading to Next 9.1.6 I am having a problem running my next js server locally. I get
[ error ] ./node_modules/destroy/index.js
Module not found: Can't resolve 'fs' in '**/node_modules/destroy'
When running npm run dev
, however this change seems to be working fine in production it just happens locally when running the hot reloading server
Describe the bug
^^ Look at above description
I think it might possibly have to do with this change. We are no longer requiring fs
in the hot reloader https://github.com/zeit/next.js/commit/fd95d6c8bc3c6e89cdf8f84b11146bf86e377ee0#diff-6161346d2c5f4b7abc87059d8768c44bL1
To Reproduce
Edit:
Clone this repo https://github.com/iteratelabs/next-not-working
use node version 10.15.3
npm install
run the command npm run dev
and you should get a module not found error.
Expected behavior
Expected behavior is for the development server to still run the web application after upgrading.
Screenshots

System information
- OS: macOS
- Version of Next.js: 9.1.6
Additional context
EDIT: I downgraded to 9.1.5 and still get the same error however. Was not getting this error previously though until today
I took a look at this issue https://github.com/zeit/next.js/issues/7755 and added
if (!isServer) {
config.node = {
fs: 'empty'
}
}
to my webpack config but then I got the following error
[ error ] ./node_modules/express/lib/request.js
Module not found: Can't resolve 'net' in '**/node_modules/express/lib'
So now I have
if (!isServer) {
config.node = {
fs: 'empty',
net: 'empty'
}
}
Which allows me to build the webapp and run it in the development server but I get this warning
[ warn ] ./node_modules/express/lib/view.js
Critical dependency: the request of a dependency is an expression
Issue Analytics
- State:
- Created 4 years ago
- Comments:20 (7 by maintainers)
I got this problem when I was converting function to class element vc code accidentally auto imported
import { render } from "node-sass";
Just got the same error when I was importing an object in a front-end page but the object was defined in an API route which includes server-side imports. Solution was to export the object from its own file so the (unrelated) imports wouldn’t get in the way.
Might be a common mistake which is why I’m dropping this here as one possible solution. The error message could definitely be more helpful about which import exactly is causing the trouble 😅 Here’s what it looks like with
next@9.5.3
: