whatwg-fetch -> isomorphic-fetch

[derhuerst]

In order to make @parity/parity.js more portable, this PR removes the brittle & discouraged environment sniffing and uses isomorphic-fetch, which adds a cross-platform global fetch.

[jacogr]

Really not sure why we ended up with both whatwg-fetch and isomorpic-fetch since the original API implementations only used the latter - however it wasn't actually build-time included since the build used Rollup. (only a dependency in package.json)

Possibly due to merging with the codebases?

@ngotchac I remember us having a discussion at some point around this when the node-fetch/browser-fetch came up. Please do take a look.

This would obviously need to have a full binary build done to test if the served version works as expected when dapps request the libraries, i.e. cargo build --release --no-default-features --features ui

[ngotchac]

So here's the issue : we are building/transpiling our published libraries. Thus, on build time, Webpack has to know for each module which file to parse and include. To do that, it looks at the package.json file of each dependant modules. Let's say we use isomorphic-fetch : it will look at the browser field, than at the main field. For isomorphic-fetch, it will thus use the browser field, since it's available. In the end, the browser field of isomorphic-fetch just points to a file that requires whatwg-fetch. So for anyone using our library for a browser build, it will be fine, but not for those using it in a Node envrironment.

There is no real solution IMO, except those 2:

• Have two builds per library, one for a browser and one for node, and explicit those 2 version in the published package.json file.
• Let the user polyfill the fetch API if needed

[ngotchac]

I couldn't agree more on the fact that we currently do it the wrong way. To use it for the chrome extension, I had use some tricks in order not to polyfill the fetch API. That's why I personally prefer the second option. Plus, we should publish our source/ES6 code to NPM and point to the right file in package.json. Not everybody needs the compiled un-readable code

[derhuerst]

So here's the issue : we are building/transpiling our published libraries. […] For isomorphic-fetch, [webpack] will thus use the browser field, since it's available. […] So for anyone using our library for a browser build, it will be fine, but not for those using it in a Node envrironment.

Usually you publish libraries (to npm) in an unbundled, but transpired form. afaict this would fix the problem as well, right?

this has also the nice effect that stack traces are actually readable, as once can easily jump to the original file to see what's going on.

• Let the user polyfill the fetch API if needed

If we don't take the approach described above (which i strongly recommend), 👍

[jacogr]

Since we do a seperate library build -

1. build-in to build for web to be served via /parity-utils/{inject,parity).js - this includes the browser fetch polyfill (hopefully what webpack includes)
2. published version to have no built-in version, but rather isomorphic-fetch in package.json

[ngotchac]

Yes I think that would work (one bundled version via Webpack, one transpiled version that gets published)

[derhuerst]

I started to work on a setup that only transpires & publishes jsonrpc, parity.js, etherscan and shapeshift in the jr-simplify-release branch over at #4479.

[derhuerst]

Closing in favour of #4479. See de56706 specifically.