Support js-ipfs-http-client use in React Native env

[pcowgill]

This would involve adding a react-native field in the package.json equivalent to the browser one that already is in there and ensuring that the appropriate react-native-compatible implementations of node core modules are used.

The list of react-native compatible versions can be found here and/or here.

It would also involve only using 3rd party deps that also have these criteria met when in a React Native env.

There's a more specific issue about a particular problem one runs into using this lib in a React Native env, but this issue is about the more general need for React Native support, so it should persist even if that issue gets resolved first.

This is a complementary issue to the one over in the aegir repo.

[alanshaw]

Any chance you can help us out with this @pcowgill? I think in the new version we're not using most of those modules (since we've shifted to more browser focused APIs), but it would be good to know where we currently don't.

Ideally we wouldn't have a react-native field in package.json.

[pcowgill]

@alanshaw Yep, I'm definitely interested in helping out with this.

It's too bad that ky assumes a browser or deno environment. ky wraps fetch, and fetch in a React Native env doesn't have streams implemented.

It would be nice if this lib's dep was something more universal rather than something that assumes a browser env. ky-universal supporting a node environment as well is nice, but that doesn't address the React Native use case.

When you say that you're not using most of those modules, do you means ones for which we'd need a node core polyfill or ponyfill? I know you're moving away from iso-stream-http, but I wasn't sure about the timeline for that yet. (Related discussion here)

@alanshaw What's unappealing about having a react-native field in package.json?

1. Is it your preference to have a polyfill available in this lib for use in a React Native env, or do you think the responsibility of using a polyfill lands with each React Native dev using this lib? That seems like unnecessary duplication of work.
2. Or were you picturing a rn-compatible fork that we somehow keep in sync rather than using a react-native field in package.json?
3. Or something else? Like a more universal alternative to ky?

[pcowgill]

Some issues that would get this moving in a good direction (they're all distinct steps so I don't think it makes sense to merge them):

https://github.com/ipfs/js-ipfs-http-client/issues/1215
https://github.com/ipfs/js-ipfs-http-client/issues/1217
jonnyreeves/fetch-readablestream#10
facebook/react-native#27741

[pcowgill]

@alanshaw What's unappealing about having a react-native field in package.json?

@alanshaw I'm still curious about this when you have a moment. Thanks!

[achingbrain]

Will be fixed by #2813

[pcowgill]

I'll close this issue and we can track this issue in the newer one @achingbrain linked to.