是否可以在React Native中填充Node的fs.readFileSync（）？

Question

我想将许多为NodeJS编写的软件包移植到React Native。

为此，我使用了流行的Ignite样板创建了一个RN项目，然后使用了ReactNativify方法和shim Node API对象，这些对象主要重用了现有的browserify垫片 。

（有关详细信息和一些有用的技巧，请参阅我们可以在react native应用程序中使用nodejs代码吗？ ）

编译后，某些Node对象仍被空的模拟替换，例如fs 。 在.babelrc中进行如下操作：

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

        // etcetera
      }
    }]

port的软件包在其传递依赖fs.readFileSync中包含对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，但它没有实现同步文件系统方法。

然后是brfs转换，例如brfs ， “ browserify fs.readFileSync（）静态资产衬里” （及其替代品bfrs-babel和babel-plugin-static-fs ）。

但是我不知道如何将它们包括在内，它们是否甚至可以在RN中使用？

所以我看到了四种方法：

1. 找到一种方法来将react-native-level-fs和brfs合并为可用的填充垫片替换
2. 编写具有所有方法的全新fs垫片
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 

Answer 1

否fs.readFileSync的fs.readFileSync没有合理的选择。

尽管从技术上讲，可以编写阻塞异步文件操作的readFileSync填充程序，但不建议在异步系统中强制执行同步行为（但是，当一个同步方法中只有很少的同步方法时，您可以摆脱它。时间初始化代码）。

因此，选项3或4是唯一可行的选择。

在我的案例中，Node依赖关系太多，因此我放弃了browserifying / shimming并选择了4。但是...

这并不意味着所有事情都必定会丢失。 我现在正在研究将NodeJS编译为Android中的本机库

（ 和Realm.io可以在Android胖客户端应用程序（CQRS风格）中桥接本机NodeJS + React Native ）。