Client config builder

[pileks]

Works towards resolving #1122

1st implementation of Client Config Builder. Very basic, follows the config logic that’s already present within the Client.

Future work:

• Set up config bundles for various use-cases (Ethereum/ENS, IPFS etc.)
• Create addX (addPlugin, addEnv, etc.) methods
• Consider & implement different config add/override behavior
  • Currently, the 1st config for a given plugin/env/etc. is used, making stuff like chaining .add() calls behave unintuitively
  • My personal preference for config builders is to have whatever comes last be the value used within the config
  • Possible solution - have two base methods: add and set, with their respective addX and setX for each config section (plugins, envs, etc.)
    • add would append, while set would overwrite
    • behavior would need to be examined and determined per config section (what does it mean to add an interfaceImplementation vs add a plugin, for example?
• Load config from a file? (JSON, TOML?)

Comments/thoughts very welcome!

[pileks]

I went ahead and fixed the conflicts. Once again thanks for this @pileks - Amazing job :-D

Thanks @cbrzn! I've updated another related PR with the merge, you might want to check it out: https://github.com/polywrap/monorepo/pull/1135

[dOrgJelli]

Apologies for taking so long to review this @pileks, this was really well executed given how many potentially moving parts there are + legacy code. A few things I think we should remove in the next release (after this is out):

• @polywrap/client-js: createPolywarpClient(...) + js/client/scripts/*
• Move the ETH + IPFS + ENS defaults out of the @polywrap/client-config-builder package, and into their own "config bundle" package. Maybe call it @polywrap/eth-ens-ipfs-config-js.
  • Maybe have another "config bundle" package named @polywrap/http-ws-config-js. Not sure what to do about the FileSystem plugin and any others that are missed here...
  • Not even sure we need these "bundle packages". Could just move the "sane defaults" into their respective plugin packages import { plugin, defaults } from "some-plugin"