I made a React Native for Windows app for testing RNFS.
This is my App.ts:
import React, { Component } from 'react';
import { Text, View } from 'react-native';
import RNFS from 'react-native-fs';
const str = RNFS.MainBundlePath;
class App extends Component
{
render()
{
return React.createElement(View, null, React.createElement(Text, null, str));
}
}
export default App;
But when I ran react-native run-windows command, this error happens:
Error: EISDIR: illegal operation on a directory, read
at Object.readSync (fs.js:592:3)
at tryReadSync (fs.js:366:20)
at Object.readFileSync (fs.js:403:19)
at UnableToResolveError.buildCodeFrameMessage (C:\Users\gpffl\Desktop\foo\node_modules\metro\src\node-haste\DependencyGraph\ModuleResolution.js:304:17)
at new UnableToResolveError (C:\Users\gpffl\Desktop\foo\node_modules\metro\src\node-haste\DependencyGraph\ModuleResolution.js:290:35)
at ModuleResolver.resolveDependency (C:\Users\gpffl\Desktop\foo\node_modules\metro\src\node-haste\DependencyGraph\ModuleResolution.js:191:15)
at DependencyGraph.resolveDependency (C:\Users\gpffl\Desktop\foo\node_modules\metro\src\node-haste\DependencyGraph.js:353:43)
at C:\Users\gpffl\Desktop\foo\node_modules\metro\src\lib\transformHelpers.js:271:42
at C:\Users\gpffl\Desktop\foo\node_modules\metro\src\Server.js:1097:37
at Generator.next (<anonymous>)
And this is my system spec:
System:
OS: Windows 10 10.0.19041
CPU: (4) x64 Intel(R) Core(TM) i5-4200M CPU @ 2.50GHz
Memory: 534.39 MB / 3.92 GB
Binaries:
Node: 14.15.4 - C:\Program Files\nodejs\node.EXE
Yarn: 1.22.10 - ~\AppData\Roaming\npm\yarn.CMD
npm: 6.14.10 - C:\Program Files\nodejs\npm.CMD
Watchman: Not Found
SDKs:
Android SDK: Not Found
Windows SDK:
AllowDevelopmentWithoutDevLicense: Enabled
AllowAllTrustedApps: Enabled
Versions: 10.0.18362.0
IDEs:
Android Studio: Not Found
Visual Studio: 16.8.30907.101 (Visual Studio Community 2019)
JetBrains Webstorm: 2020.3.1
Languages:
Java: Not Found
Python: 2.7.18
npmPackages:
@react-native-community/cli: Not Found
react: 16.13.1 => 16.13.1
react-native: 0.63.4 => 0.63.4
react-native-windows: ^0.63.0-0 => 0.63.24
npmGlobalPackages:
*react-native*: Not Found
Why this happens?
Had the same issue while testing something in react-native 0.63.2 in macOS
I have the same issue on macOS but I don't use react-native-fs. This looks more like a react native or metro issue.
@levani it's a React-native issue i think. the error is linked to the metro dependancies inside node_modules.
Just so you're aware, the EISDIR error is likely to be a misreported error due to a bug in metro that has been fixed in metro 0.65. The underlying error is likely to be an import issue (similar to what I found here) but that needs to be verified. I faced that problem with a bunch of other libraries.
You can try to manually patch the metro library in your node_modules if you want to see what is the actual error.
Just so you're aware, the
EISDIRerror is likely to be a misreported error due to a bug in metro that has been fixed in metro 0.65. The underlying error is likely to be an import issue (similar to what I found here) but that needs to be verified. I faced that problem with a bunch of other libraries.You can try to manually patch the metro library in your
node_modulesif you want to see what is the actual error.
Definitely can be a misreported error. Just had this when I had a typo in a style property name.
how to fix that?
adding some logs into metro's Server.js helped me get to the bottom of why it was throwing this error. Which ended up being a debugger-ui source map issue. In fact when I looked at the Chrome console logs I was seeing specific file warnings that showed every time the EISDIR showed in expo logs
adding some logs into metro's Server.js helped me get to the bottom of why it was throwing this error. Which ended up being a debugger-ui source map issue. In fact when I looked at the Chrome console logs I was seeing specific file warnings that showed every time the EISDIR showed in expo logs
Same for me, when I enable "Debug", http://localhost:8081/debugger-ui/ open then the error will show, but my app still work
same issue facing in mac
same here everytime I run debug mode in react native. does anyone here have a fix for this?
Add patch-package to your project with yarn add patch-package and the "postinstall": "patch-package" script (see its installation instructions).
Then create a patch file patches/metro+0.59.0.patch with these contents:
diff --git a/node_modules/metro/src/node-haste/DependencyGraph/ModuleResolution.js b/node_modules/metro/src/node-haste/DependencyGraph/ModuleResolution.js
index 92c8a7e..ebab5d0 100644
--- a/node_modules/metro/src/node-haste/DependencyGraph/ModuleResolution.js
+++ b/node_modules/metro/src/node-haste/DependencyGraph/ModuleResolution.js
@@ -303,7 +303,7 @@ class UnableToResolveError extends Error {
try {
file = fs.readFileSync(this.originModulePath, "utf8");
} catch (error) {
- if (error.code === "ENOENT") {
+ if (error.code === "ENOENT" || error.code === 'EISDIR') {
// We're probably dealing with a virtualised file system where
// `this.originModulePath` doesn't actually exist on disk.
// We can't show a code frame, but there's no need to let this I/O
Now run yarn again or just yarn postinstall and Metro should be patched to unmask the EISDIR error and reveal the actual problem with your setup.
Note: If you're using RN 0.64 I believe you will be on Metro 0.64 and not 0.59. In that case you will need to create your own patch file for the new version by following the patch-package instructions.
in my case is for reanimated in the react navigation 5, remove this code from MainApplication.java works fine the debug
@Override
protected JSIModulePackage getJSIModulePackage() {
return new ReanimatedJSIModulePackage(); // <- add
}
Same issue on RN 0.64.1 on mac, any solution?
@ghasemikasra39 RN 0.64 uses Metro 0.64 and the fix is in Metro 0.65, so you still need to patch Metro to unmask the actual issue you are having. See my comment about creating a patch with patch-package above.
it a problem with the node js
Just so you're aware, the
EISDIRerror is likely to be a misreported error due to a bug in metro that has been fixed in metro 0.65. The underlying error is likely to be an import issue (similar to what I found here) but that needs to be verified. I faced that problem with a bunch of other libraries.
You can try to manually patch the metro library in yournode_modulesif you want to see what is the actual error.Definitely can be a misreported error. Just had this when I had a typo in a style property name.
how to fix that?
Add
patch-packageto your project withyarn add patch-packageand the"postinstall": "patch-package"script (see its installation instructions).Then create a patch file
patches/metro+0.59.0.patchwith these contents:diff --git a/node_modules/metro/src/node-haste/DependencyGraph/ModuleResolution.js b/node_modules/metro/src/node-haste/DependencyGraph/ModuleResolution.js index 92c8a7e..ebab5d0 100644 --- a/node_modules/metro/src/node-haste/DependencyGraph/ModuleResolution.js +++ b/node_modules/metro/src/node-haste/DependencyGraph/ModuleResolution.js @@ -303,7 +303,7 @@ class UnableToResolveError extends Error { try { file = fs.readFileSync(this.originModulePath, "utf8"); } catch (error) { - if (error.code === "ENOENT") { + if (error.code === "ENOENT" || error.code === 'EISDIR') { // We're probably dealing with a virtualised file system where // `this.originModulePath` doesn't actually exist on disk. // We can't show a code frame, but there's no need to let this I/ONow run
yarnagain or justyarn postinstalland Metro should be patched to unmask the EISDIR error and reveal the actual problem with your setup.Note: If you're using RN 0.64 I believe you will be on Metro 0.64 and not 0.59. In that case you will need to create your own patch file for the new version by following the
patch-packageinstructions.
If you are using Metro 0.64. This is patch. Make file patches/metro+0.64.0.patch with this context:
diff --git a/node_modules/metro/src/node-haste/DependencyGraph/ModuleResolution.js b/node_modules/metro/src/node-haste/DependencyGraph/ModuleResolution.js
index 5f32fc5..2b80fda 100644
--- a/node_modules/metro/src/node-haste/DependencyGraph/ModuleResolution.js
+++ b/node_modules/metro/src/node-haste/DependencyGraph/ModuleResolution.js
@@ -346,7 +346,7 @@ class UnableToResolveError extends Error {
try {
file = fs.readFileSync(this.originModulePath, "utf8");
} catch (error) {
- if (error.code === "ENOENT") {
+ if (error.code === "ENOENT" || error.code === 'EISDIR') {
// We're probably dealing with a virtualised file system where
// `this.originModulePath` doesn't actually exist on disk.
// We can't show a code frame, but there's no need to let this I/O
and follow instruction of @marnusw
Just so you're aware, the
EISDIRerror is likely to be a misreported error due to a bug in metro that has been fixed in metro 0.65. The underlying error is likely to be an import issue (similar to what I found here) but that needs to be verified. I faced that problem with a bunch of other libraries.
You can try to manually patch the metro library in yournode_modulesif you want to see what is the actual error.Definitely can be a misreported error. Just had this when I had a typo in a style property name.
how to fix that?
look my comment from above
Is it possible to upgrade the metro version to 0.66.0 and RN still remains 0.64?
Most helpful comment
how to fix that?