Client: Externalizing Default Plugins

Problem

In our current software-dependency diagram (very WIP), the client has too many dependencies. This is primarily due to the “Default Plugins” section:
image

These plugins are being used to “boostrap” the client with commonly used capabilities.

The left column [fs, logger, http] are used for common “system capabilities”.
The right column [ens, ethereum, ipfs] are used for “URI resolution” (more on that here).

Solution

We should externalize the plugins, and instruct developers with how they can configure their clients with “bundles” of plugins (and other client configurations).

@Dr.Manhattan @Jure didn’t you build a spec for this? I can’t find it in my hackmd…

1 Like

Yes, I think you’re referring to this: Web3ApiClient Config - HackMD

1 Like

That’s exactly it :clap:

I’m curious what you think the implementation strategy should be for this. Should there be a JS package named “@polywrap/client-config-builder-js”?

I think it’s best to have it in its own package, so that we can upgrade it in the future to work with multiple types of clients. It can help us solve future compatibility issues, for example making old plugins work with newer clients.

We’d also have packages that are “configuration presets” for the config builder to use. These would effectively be JS modules that export an instance of the PolywrapClientConfig interface, which would be combined with other configurations.

I’d go with either a separate package or have it included in the core-js package.
I’m leaning a bit more towards the latter, at least for the time being until it makes sense to extract it.
The reasoning is that the builder can definitely be used without the client (e.g. when creating your own config presets), but cannot be used without the core.

1 Like