Updates for a modern SDK

[BenRacicot]

MIGRATED from js-stellar-base/issues/532

After digging into the SDK and the API I've noticed several issues and some true roadblocks for front-end web applications.

1. Webpack 5
   The SDK currently uses Webpack 4.33.0. This is a roadblock for some modern apps and frameworks
   (WP 5 environments)
2. Eventsource (and Webpack 4) is a roadblock [732]
   In a Webpack 5 world EventSource and its deps must be polyfilled. This is a compounded issue because the SDK's version 1.0.7 (> 4 years old) likely requires polys that match its own dependencies' versions.
3. TypeScript
   TypeScript 3.4.5 is outdated and an optimized TS developer experience is healthy, safer and easier for everyone.
4. BigNumber
   To get started I spent an hour debugging rt.times(...).greaterThan is not a function which was fixed by falling back to "bignumber.js": "8.0.1" from 9.0.2. Since we need BigNumber it would be recommended that the SDK team drives compatibility and guidance here.
5. ECMA script modules
   confirm the SDK is exporting code in a recent ECMA standard.

ECMAScript modules are the official standard format to package JavaScript code for reuse.

[wildework]

I'm fully behind this request. Webpack 5 support is table stakes, EventSource seems like extra complexity without any benefits, given how promises and cursors can get all the same data.

[orbitlens]

@Shaptic Awesome work! Great to see that you are modernizing JS packages.

In addition to the existing changes it would be nice to drop some dependencies:

• es6-promise polyfill (stellar-sdk) is redundant, native Promise is available everywhere
• urijs (stellar-sdk) is obsolete, browser/node built-ins provide the same functionality
• lodash (everywhere) adds a bloat to the bundle and lodash function are much slower than native Array/Object prototype methods
• bignumber.js (everywhere) can be safely replaced with native BigInt (supported in all evergreen browsers)
• base32.js (stellar-base) doesn't support tree-shaking, and the only function used from the package can be easily optimized and inlined

Other suggestions:

• sha.js can be potentially replaced with native functionality (modern browsers support sha256 hashing via browser crypto API, NodeJS also has full native support). I'm almost certain that we can get rid of the sha.js dependency, but need to conduct a small research in this field to be 100% sure.
• typescript and utility-types (stellar-sdk), crypto-browserify (stellar-base), as well as all typescript-related @types/{something} mappings should probably be located in the devDependencies section

I can help with some of this work. Removing redundant dependencies will result in a dramatic bundle size decrease for most Stellar-related webapps, not to mention better performance and lighter memory footprint.

[Shaptic]

aaand I'm back 🏖️

Thank you for the comprehensive list of suggestions, @orbitlens; your expertise and input here is deeply appreciated 🙏 Please feel free to make contributions as you see fit, though there's no pressure: I will slowly work my way through this list as well!