Plugin refactor

[nerfZael]

Description:

The goal of this refactor is to remove plugins from the core-js, and client-js packages and improve their composability with resolvers This PR introduces a new plugin-js package where the PluginWrapper and PluginPackage classes are located.

Features:

• client-js
  • Polywrap Client now re-exports the config builder and uri-resolvers (in addition to core) packages. This is done to improve dev exp and remove the need for users to import those package themselves.
    • For users who do not need those package and are using noDefaults there will be a separate PR that refactor core client functionality into a core-client package that does not depend on the config builder and uri-resolvers packages, but has no defaults.
• config-builder-js
  • Added addRedirects, addWrappers, addPackages methods to the ClientConfigBuilder, so users can add many items at once.
  • Added buildDefault to the ClientConfigBuilder which builds a ClientConfig using default resolvers.
• plugin-js
  • New package for plugins
  • Can create plugin packages with PluginPackage.from
    • Accepts manifest and a PluginModule or an inline PluginModule
• uri-resolvers-js
  • Added StaticResolver and StaticResolver.from to optimize building resolvers with IUriRedirect, IUriWrapper and IUriPackage.
• schema-bind-js
  • In the module template, PluginModule is now imported fron plugin-js instead of core-js

Breaking changes:

• client-js
  • The Polywrap Client with noDefaults: false no longer accepts a plugins field, but it accepts wrappers and packages.
    • resolver field has been replaced with resolvers, since with default client the resolver used is the RecursiveResolver with the PackageToWrapperCacheResolver.
  • The Polywrap Client with noDefaults: true, no longer accepts a plugins field. It is expected that devs using this option will manually configure their own resolver.
  • removed getPlugins and getPluginByUri. Will add getWrapper, getWrapperByUri, getPackage, getPackageByUri, in a follow up PR.
  • createPolywrapClient function has been deleted from the client-js package as it is unnecessary
• config-builder-js
  • Now uses the CustomClientConfig which doesn't have plugins and a resolver, but now has wrappers, packages and resolvers
  • Calling build returns an instance of the CustomClientConfig, which can be used with defaults from the PolywrapClient, but can not be used if noDefaults: true is passed to the PolywrapClient constructor.
  • Removed addPlugin from the ClientConfigBuilder, users can now use addWrapper or addPackage where appropriate.
  • Renamed addUriRedirect to addRedirect to keep it inline with addWrapper and addPackage (IUriRedirect, IUriWrapper, IUriPackage)
• core-js
  • Plugins are no longer a part of this package, they have been moved to the plugin-js package
  • Renamed UriRedirect to IUriRedirect to match IUriWrapper and IUriPackage
  • IUriRedirect, IUriWrapper and IUriPackage are now generic and their generic param implements Uri | string
  • Removed options argument from client.getManifest method since all wrappers have a deserialized manifest
• react-js
  • Replaced plugins on the PolywrapProvider with wrappers and packages
• uri-resolvers-js
  • Replaced helper func buildUriResolver with UriResolver.from
  • Constructors of built-in resolvers like RecursiveResolver and PackageToWrapperCacheResolver now accept a concrete IUriResolver while their static from methods accept a UriResolverLike
  • Remove PluginsResolver and PluginResolver, users can now use WrapperResolver or PackageResolver

[lgtm-com[bot]]

This pull request introduces 200 alerts when merging f4b5f9280ee1d139aa1dada9f22cfe6d34b43b78 into dadd0f8f957f0eb6aa5b3a542a65fb798006a428 - view on LGTM.com

new alerts:

• 197 for Syntax error
• 3 for Unused variable, import, function or class

[lgtm-com[bot]]

This pull request introduces 6 alerts when merging 2f11deedca9a302e13a66368375dbe0149b3f93e into 30f7f64f342d610f997af5daeaff0eb4b59d8f2d - view on LGTM.com

new alerts:

• 6 for Unused variable, import, function or class

[nerfZael]

nit feel free to ignore: i am noticing a pattern in plugin tests where we have a getClient function - would it makes sense to use the config builder so we start to use this pattern in the toolchain?

@cbrzn Only in the places where we want to test the config builder and or the default client config. Ideally, tests test just a single functionality, so they should depend on the least amount of deps and use a client with only the necessary packages configured. That's why in most of the tests I'm using noDefaults: true on the client ctor.