Is your feature request related to a problem? Please describe.
With the latest changes to the ClientConfigBuilder and its new BuilderConfig object outlined in #1480, we are converging onto a unified system of configuration, which consists of:
BuilderConfig as the config object used by the ClientConfigBuilder internallyClientConfigBuilder which can spit out a CoreClientConfig, andCoreClientConfig, which is now used both within the PolywrapCoreClient and the PolywrapClient
With this convergence, we have 3 "vestigial" config objects which the PolywrapClient accepts and transforms into a CoreClientConfig using the ClientConfigBuilder:
PolywrapClientConfigClientConfigPolywrapCoreClientConfig
Describe the solution you'd like
We could (and likely should) remove these 3 vestigial config types before 0.10 in order to facilitate a less confusing configuration experience. This would include removing everything from the legacy folder in packages/js/client, including the now public-facing generic types for Envs, etc.
My proposal is that PolywrapClient's constructor only accepts CoreClientConfig, which can be built using the ClientConfigBuilder.
I'm on the fence about whether we'd want PolywrapClient's constructor to accept a BuilderConfig object, as this seems to be the last place where there is a dependency between @polywrap/client-js and @polywrap/client-config-builder-js. Separating these two isn't a top priority, but it would be nice to have, as we could have each of them then be 100% focused on their own concerns.
Describe alternatives you've considered
We can keep this legacy folder alive for however long we'd like, but we're then nudging developers into 4 separate ways of setting up the PolywrapClient - not ideal IMO.
Additional context
/
Is your feature request related to a problem? Please describe.
With the latest changes to the ClientConfigBuilder and its new BuilderConfig object outlined in #1480, we are converging onto a unified system of configuration, which consists of:
BuilderConfigas the config object used by theClientConfigBuilderinternallyClientConfigBuilderwhich can spit out aCoreClientConfig, andCoreClientConfig, which is now used both within thePolywrapCoreClientand thePolywrapClientWith this convergence, we have 3 "vestigial" config objects which the
PolywrapClientaccepts and transforms into aCoreClientConfigusing theClientConfigBuilder:PolywrapClientConfigClientConfigPolywrapCoreClientConfigDescribe the solution you'd like
We could (and likely should) remove these 3 vestigial config types before
0.10in order to facilitate a less confusing configuration experience. This would include removing everything from thelegacyfolder inpackages/js/client, including the now public-facing generic types for Envs, etc.My proposal is that
PolywrapClient's constructor only acceptsCoreClientConfig, which can be built using theClientConfigBuilder.I'm on the fence about whether we'd want
PolywrapClient's constructor to accept aBuilderConfigobject, as this seems to be the last place where there is a dependency between@polywrap/client-jsand@polywrap/client-config-builder-js. Separating these two isn't a top priority, but it would be nice to have, as we could have each of them then be 100% focused on their own concerns.Describe alternatives you've considered
We can keep this
legacyfolder alive for however long we'd like, but we're then nudging developers into 4 separate ways of setting up the PolywrapClient - not ideal IMO.Additional context
/