Open stovmascript opened 8 years ago
@stovmascript i hadn't seen ReactNativify, thanks for bringing it to my attention! On the one hand, it's a much less hacky approach than rn-nodeify. On the other hand, i'm not sure how ReactNativify gets around the various issues that come up in random modules here and there due to the differences between RN packager and webpack/browserify, specifically the cases solved by pkg-hacks.js. Have you tried it out?
Hi, author of ReactNativify here. We use this approach in production with a pretty sizable code base that's shared between node.js on embedded devices, node.js on the server, webapps packaged by webpack, and React Native apps. We use crypto and streams heavily, and lots of third party packages that depend on those.
We haven't found the need for any major hacks at all. This is literally the extent of the amount of runtime patching we do to the global object:
global.Buffer = require('buffer').Buffer;
global.process = require('process');
global.process.env.NODE_ENV = __DEV__ ? 'development' : 'production';
// This is to make the `debug` module happy.
if (typeof global.document === 'undefined') {
global.document = {documentElement: {style: {}}};
}
Check out the example node module that's supplied in the repo. It's imported into the React App, and it's also runnable from the command line by invoking node node.js
. It uses crypto and streams just fine.
Let me know if there are any other questions I can answer. I'd love to make sure this approach works for most everyone.
@philikon Thanks for bringing ReactNativify to my attention (again, i forgot about it)! I think it's a healthier approach than this package. I would love to see a more serious proof of concept, e.g. if you could get webtorrent running in react native. Honestly, I haven't done "the webtorrent test" with rn-nodeify in a while, but that was what I was testing it with in the early days, and man, there were so many edge cases where the packager would choke. I really hope it's easier today.
Curious, are you using webtorrent as a litmus test, or do you actually have business needs to run it inside a React Native app?
@philikon exactly, litmus test. For my own project's needs i need bitcoinjs-lib, a bunch of other crypto stuff, levelup and related packages, and lots of stream stuff
The node crypto
and stream
packages from Node work without problems.
Is there a simple bitcoinjs-lib
example that I could include in the ReactNativify demo? I think that'd be fun, and perhaps it'll get you closer to being able to use ReactNativify.
hm, not off the top of my head, but I'm sure there are. Btw, for your crypto example, u might want some more serious randomness: https://github.com/mvayngrib/react-native-randombytes
Oh yeah, I explicitly wanted to keep it simple and not mess with linking in native code. Internally we obviously use the native RNG :)
But thanks for the tip, I've updated the comment to refer to your package.
ah yea, makes sense :) Please do keep me updated on how ReactNativity develops, and what kind of problems you run into (hopefully none of course). I see I've already upvoted https://productpains.com/post/react-native/packager-support-resolvealias-ala-webpack It's definitely a pain point in RN that I think the core team is severely underestimating.
Thanks for the upvote. FWIW, ReactNativify's approach of combining rn-cli.config.js
with a custom transformer and a Babel import rewrite plugin is pretty much equivalent to webpack's resolve aliases. At least for us this approach has been totally sufficient, and we use it a lot to bridge differences between browser, RN, and node.js (lots of native modules, for instance.)
FWIW, I added a super simple bitcoin-lib example to ReactNativify (creating a transaction), cribbed from their unit tests. Any further suggestions or PRs to add more examples are very welcome! :)
@philikon awesome, I will definitely play around with ReactNativify, though probably not until March. There are some hard deadlines for a few projects and I don't want to experiment with the build system before the delivery (as much as I want to experiment with the build system).
We should consider renaming this issue to say metro.config
rather than rn-cli.config
now that that's the new naming convention.
Hey @mvayngrib, have you by any chance come across this repo? It shows an interesting alternative method to rn-nodeify, namely in that it uses some built in RN functionality. There are tradeoffs, which I've highlighted here: https://github.com/akfish/node-vibrant/issues/29#issuecomment-258684020.
I was thinking that implementing the transform and babel-plugin-rewrite-require into rn-nodeify would be possible, but am curious what you think about it?