是否可以在 React Native 中填充 Node 的 fs.readFileSync()?

Is it possible to shim Node's fs.readFileSync() in React Native?

我想将一些为 NodeJS 编写的包移植到 React Native。

为此,我使用流行的 Ignite 样板创建了一个 RN 项目,然后使用 ReactNativify method and shim Node API objects mostly reusing existing browserify shims

(有关详细信息和一些有用的提示,请参阅

一些 Node 对象在转译后仍然被替换为空模拟,例如 fs.babelrc 完成如下:

    ["module-resolver", {
      "alias": {
        "fs": "./config/mock",
        "sodium-universal": "libsodium"

        // etcetera
      }
    }]

要移植的包在其传递依赖项中包含对 fs.readFileSync 的多次调用。

例如其中一个,hypercore-protocol,有这行代码:

module.exports = protobuf(fs.readFileSync(path.join(__dirname, 'schema.proto'), 'utf-8'))

这里有个问题,因为Android和iOS不支持同步文件传输。那条线在我看来是 un-shim-able

现在,虽然存在 fs 的垫片:react-native-level-fs 它没有实现同步文件系统方法。

然后是 browserify 转换,例如 brfs, the 'browserify fs.readFileSync() static asset inliner' (and its alternatives bfrs-babel and babel-plugin-static-fs)。

但我不知道如何将它们包括在内,它们是否会在 RN 中工作?

所以我看到了四种前进的方法:

  1. 找到一种方法将 react-native-level-fsbrfs 合并为可用的 shim 替代品
  2. 编写一个全新的 fs shim,它具有所有方法
  3. 如果同步 fs 不可能(我认为是),则以某种方式覆盖整个调用同步方法的传递依赖树中所有出现的函数,并用本地代码库中的 js 片段替换它们
  4. 如果3.出现的次数过多,则决定该包不能移植到React Native

我希望 1. 或者 3. 成为可行的解决方案。有人可以建议吗?

为了完整起见。我在这个人生阶段:

System
  platform           linux                                                                                                
  arch               x64                                                                                                  
  cpu                4 cores   Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz                                                        

JavaScript
  node               7.10.1       /usr/local/bin/node  
  npm                4.2.0        /usr/local/bin/npm   
  yarn               0.24.6       /usr/bin/yarn        

React Native
  react-native-cli   2.0.1       
  app rn version     0.45.1      

Ignite
  ignite             2.0.0        /usr/local/bin/ignite  

Android
  java               1.8.0_111    /usr/bin/java  
  android home       -            undefined 

没有。 Node 的 fs.readFileSync.

没有合理的替代方案

虽然从技术上讲,可以编写一个 readFileSync 填充程序来阻止异步文件操作,但不建议在异步系统中强制执行同步行为(但您可能能够摆脱它,当一次性初始化代码中只有很少的同步方法时)。

所以选项 3 或 4 是唯一可行的选择。

在我的例子中,有太多的 Node 依赖项,所以我放弃了浏览器化/填充并选择了 4。但是...

这并不意味着一切都必然会丢失。我现在正在调查

(Realm.io to bridge native NodeJS + React Native in Android fat client app (CQRS-style)).