Uncaught Error: Dynamic require of "fs/promises" is not supported - when importing json from @remix-run/node
See original GitHub issueWhat version of Remix are you using?
1.7.1
Steps to Reproduce
import { json } from "@remix-run/node";
export default function SomePage(props) {
return <div>
Page
</div>
}
Then yarn dev.
Expected Behavior
No errors in developer console.
Actual Behavior
Error in developer console:

package.json
{
"private": true,
"sideEffects": false,
"scripts": {
"build": "remix build",
"dev": "remix dev",
"start": "remix-serve build"
},
"dependencies": {
"@remix-run/node": "^1.7.1",
"@remix-run/react": "^1.7.1",
"@remix-run/serve": "^1.7.1",
"react": "^18.2.0",
"react-dom": "^18.2.0"
},
"devDependencies": {
"@remix-run/dev": "^1.7.1",
"@remix-run/eslint-config": "^1.7.1",
"eslint": "^8.20.0"
},
"engines": {
"node": ">=14"
},
"packageManager": "yarn@3.2.3"
}
Yarn and Node
- node version: 18.9.0
- Yarn: 3.x
NB. I tried creating the project with using Yarn 1.x and it worked fine. The problem appears after migrating to yarn 3.x
Might be related:
https://github.com/yarnpkg/berry/issues/638#issuecomment-1124629341
Looks like Yarn 3.x supports ESM module loading. So I tried the following in my .yarnrc.yml file, following the recommendations from the link above:
yarnPath: .yarn/releases/yarn-3.2.3.cjs
pnpEnableEsmLoader: true
nodeLinker: "pnp"
But this did not help.
So, the thread above makes me think that yarn 3.x should work with Remix. But it does not. I’m wondering if this is Remix or Yarn issue?
The only workaround that works for me is to rollback to using nodeLinker: node-modules.
Issue Analytics
- State:
- Created a year ago
- Reactions:3
- Comments:14 (1 by maintainers)
Top Results From Across the Web
fs/promises api in typescript not compiling in javascript correctly
The error was due to unsupported Node version 12.x which doesn't support this require statement... var promises_1 = require("fs/promises");.
Read more >Summary of import assertions and JSON modules - miyauci.me
Explain the use of import assertions in Deno, which is now supported in Deno 1.17 and can be used to safely handle JSON...
Read more >Node.js v19.3.0 Documentation
Iterates through the list of functions passed to tracker.calls() and will throw an error for functions that have not been called the expected...
Read more >Reading and writing JSON files in Node.js: A complete tutorial
The callback function is invoked with an Error object as the first argument ... Do not use require if the JSON file you...
Read more >Errors | Node.js v18 API
A generic JavaScript Error object that does not denote any specific circumstance of why the error occurred. Error objects capture a "stack trace"...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@meglio I hit this too… A temp workaround is just change how “fs/promises” imports…
You need to change this row in file
node_modules/@remix-run/node/dist/upload/fileUploadHandler.js:it is at the top of the file… but still annoys…
Explanation is on Stackoverflow So… a fix for devs must be just updating a node version… or change how they import promises from fs…
In my case, working with sessions, I had not specifically scoped my module to the server, e.g.:
session.server.ts– so the module had leaked to the client producing the titled error.