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

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?

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 44

Commits related to this issue

Most upvoted comments

how to fix that?

Had the same issue while testing something in react-native 0.63.2 in macOS

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

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.

I was having this problem on MacOS, and simply running $ yarn start —–reset-cache solved it

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
  }

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.

Same issue on RN 0.64.1 on mac, any solution?

same here everytime I run debug mode in react native. does anyone here have a fix for this?

If you modify sourceExts at metro.config.js, you should specify all extensions.

⚠️ Wrong sourceExts: ['jsx']. If you don’t specify js metro couldn’t resolve entry point — index.js

âś… Right config

module.exports = {
    resolver: {
        sourceExts: ['js', 'jsx', 'ts', 'tsx'],
    },
    transformer: {
        getTransformOptions: async () => ({
            transform: {
                experimentalImportSupport: false,
                inlineRequires: true,
            },
        }),
    },
};

same issue facing in mac

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.

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

I moved index.js to src folder, which broke it. Moving it back to root, per the SOF @anggihseptiawan provided, fixed the issue.

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

I am using expo go application and I got same error accidentally. To fix this; 1- Shake your device while application is running on expo go. 2- Stop remote debugging 3- Refresh the application

It fixed my problem.

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.

this error came up when i forgot to add a default case in my redux reducer

I got same error, but all going well after I yarn global remove wml

yarn global remove wml

that save my life

if you have never install wml, just consider some other related global libs

----update----- I got the error again even I uninstall wml staff, but I found my issue’s root cause was the watchman, after run brew uninstall watchman, all going well

------update----- Somehow, I just delete my project and git clone it again, and then yarn install, the issue was gone, I feel stranging

how to fix that?

Stop remote debugging and reload the IOS simulator fixes the issue for me

Is it possible to upgrade the metro version to 0.66.0 and RN still remains 0.64?

I finally found a solution. It was UWP permission error. I had to modify Package.appxmanifest https://learn.microsoft.com/en-us/windows/uwp/files/file-access-permissions

What exactly did you modify in Package.appxmanifest, and did you change it in Visual Studio or VSCode ?

Sorry for late response.

I recommend opening Package.appxmanifest with text editor - I used Notepad in mine.

  1. Add these lines at Package.appxmanifest:
<Package
  ...
  xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
  IgnorableNamespaces="uap mp rescap">
...
<Capabilities>
    <rescap:Capability Name="broadFileSystemAccess" />
</Capabilities>
1 2
  1. Build your app.
  2. Once you built your app, you can see it at Start Menu. Right-click it and go into Settings. You will can see filesystem permission option is enabled. 3 4

I finally found a solution. It was UWP permission error. I had to modify Package.appxmanifest https://learn.microsoft.com/en-us/windows/uwp/files/file-access-permissions

Sorry for late response. I was busy for other reasons for a while, so I wasn’t able to check this issue. I will test at React Native 0.67 . I won’t close this issue since it still looks like to have active replies. Thanks for everyone!

@levani it’s a React-native issue i think. the error is linked to the metro dependancies inside node_modules.