magic-sdk, @magic/ext, @magic bundle optimisations (browser)

✅ Prerequisites

[x] Did you perform a cursory search of open issues? Is this question already asked elsewhere?
[x] Are you reporting to the correct repository (magic-sdk)?

❓ Question

I've done done browser bundle analysis and have recommendations to reduce magic-sdk bundle size.

regenerator-runtime is packaged with cjs and esm package distributions. I have my own webpack builder and it injects the runtime already.

The regenerator runtime gets included in every sub-package, so there are several instances where the runtime is included more than once. (@magic/provider, @magic/commons, magic-sdk etc.). Removing the runtime could potentially save a bit. Here's an example:

https://github.com/magiclabs/magic-js/blob/master/packages/magic-sdk/src/index.es.ts
/* istanbul ignore file */

import 'regenerator-runtime/runtime';

export * from './index';

@magic/provider: from what I understand, @magic/provider uses localforage as the main storage library. It is quite a big bundle, considering that smaller (and pluggable) alternatives are available (db.js - 3.5kb gzipped / jsstore - 3.8kb gzipped ). Or one can supply their own localStorage class e.g. https://gist.github.com/MichalZalecki/70a831304b0e83afbc0fbad3e8577068 ( < 1kb ).
@magic/provider: our apps don't leverage the magic rpcprovider, so it would be great not to load web3-core (or supplied as a plugin to magic-sdk)

4 @magic/provider: the checkExtension helper for @magic/provider pulls in a 25kb semver library, for what can be turned into simpler vanilla js checks.

Attached is a screenshot of a client-side bundle report. I've extracted typescript files from the various packages, and ran them through my own webpack bundler.

I love magic, and use it heavily in our apps. Reducing browser bundle sizes will be a good thing for users!

🌎 Environment

Software	Version(s)
`magic-sdk`	7.0.0

magiclabs / magic-js