feat: config bundle packages

[dOrgJelli]

Features

@polywrap/client-config-builder-js

• Modular Config Bundles
  • The DefaultBundle has been broken apart into two separate bundles: sys and web3.
  • addBundle(...) has been added to the ClientConfigBuilder interface.
  • addDefaults() now calls addBundle("sys") and addBundle("web3") internally.

@polywrap/sys-config-bundle-js

• Bundled System-Level Plugins & Resolvers
  • The sys bundle includes: logger, datetime, concurrent, http, httpResolver
  • This package is compiled to run in both node.js and browsers.
  • In node.js, the bundle also includes: fileSystem, fileSystemResolver.

@polywrap/web3-config-bundle-js

• Bundled Web3 Plugins & Resolvers
  • The web3 bundle includes: ethereumProviderV1, ethereumProviderV2, ipfsHttpClient, ipfsResolver, ensTextRecordResolver, ensResolver, ensIpfsContenthashResolver.

@polywrap/config-bundle-types-js

• Base Typings For Config Bundle Packages
  • Valid config bundle packages are expected to export a bundle value, which is of type Bundle.

Bugs

@polywrap/client-js

• Improved Browser Compatability
  • Building the JS client into browser-based applications no longer requires custom polyfills to remove Node.JS dependencies.

[pileks]

All-in-all looks good. Feel free to dismiss my proposition for changes if you disagree with them.

[pileks]

A general nit I have with our project structure is that we inline a lot of these exports under “index.ts”, instead of having them in separate files. My main reason for wanting to have an export by file (and it doesn’t have to be a default export) is that it makes it easier to locate types by filename, especially when reviewing code.

Is there any particular reason for us not doing something like this?

Again, this is just a nit 😄

[dOrgJelli]

To help me better understand, can you highlight where this is happening?

[nerfZael]

Great work!