ReactNativify | How to use node.js libraries in React Native | Runtime Evironment library

The problem is that the eth-lightwallet depends on node core modules that isn't supported by React Native out of the box. The current workaround involves using rn-nodeify in order to provide shims for React Native to use instead. See this issue for react native and see this open issue from eth-lightwallet.

So there are three issues I found

• react-native-dgram-shim needs to be copied as dgram in node_modules
• stream: require.resolve('stream-browserify') needs to be used in rn-cli.config.js. The stream module you had used didn't seems to define Stream object and Stream.prototype access caused an error
• The onvif module has cam -> device -> cam, this is handled well in browserify, webpack and nodejs. But the metro packer that react-native seems not like the cyclic imported. It means the require.js of the same needs to be fixed or the cyclic dependency needs to be removed

So you either make a fix to the require.js polyfill at jscam/src/jscam/node_modules/metro/src/lib/polyfills/require.js or you change your files to remove cyclic imports by passing the required objects like below

No. There is no reasonable alternative for Node's fs.readFileSync.

Though technically it is possible to write a readFileSync shim that blocks on an asynchronous file operation, it is inadvisable to force synchronous behavior in an asynchronous system (but you may be able to get away with it, when only having few synchronous methods in one-time initialization code).

So option 3 or 4 are the only viable alternatives.

In my case there were too many Node dependencies, so I ditched browserifying / shimming and opted for 4. But ...

That does not mean all is necessarily lost. I am now investigating Compiling NodeJS as native library in Android

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

In my question I bumped into 2 problems.

The first one, tests performing against actual code, appeared to be an issue with Jest. The Jest team stated:

This is the expected behavior. Jest is supposed to run on source files. On any large codebase, generating a bundle before running tests is too slow, so Jest compiles files just-in-time, which makes it fast.

Now this is probably a miscommunication and you can use it with proper babel-jest configuration to do dynamic transforms, I did not receive further help from the team. So I decided to go for a different test platform (either Mocha, Jasmine and/or Karma).

If you want to try your luck with Jest you can follow up on this thread: https://github.com/facebook/jest/issues/4028

The second problem, code opening in a read-only panel in VS during debugging sessions, is an open issue being processed by Microsoft. You can check progress here: https://github.com/Microsoft/vscode/issues/26782

[Update: I just received further instruction from the Jest team:

@aschrijver the general way Jest handles this is by doing the transpilation itself. So you set up transformers in your config that Jest itself uses to do the transpilation.

https://facebook.github.io/jest/docs/configuration.html#transform-object-string-string

An example config for Typescript is here to give you an idea of what this could look like: https://github.com/kulshekhar/ts-jest

In terms of shims, what I think you might be wanting are actually Jest mocks. A Jest mock can step in instead of an actual module when you import or require it.

]