React-native-fs: EISDIR: illegal operation on a directory, using with React Native for Windows

Created on 12 Mar 2021  路  20Comments  路  Source: itinance/react-native-fs

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?

Most helpful comment

how to fix that?

All 20 comments

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 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.

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 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.

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-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.

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 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.

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?

Was this page helpful?
0 / 5 - 0 ratings