You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are times when the out-of-the-box plugins (i.e. transforms/handlers/etc.) aren't powerful enough to address a specific use case. The best option in these instances would be to use a custom-written plugin that allows its own custom config to be passed in. I've only been able to achieve this capability, however, by removing the validateConfig(config); statement from parse-config.ts in the runtime package.
Since we currently generate a json schema at build-time and use that for validation, this prevents us from adding our own custom plugins with their custom configs. My recommendation to solve this would be to dynamically call a 'validateConfig()' method from each plugin when parsing the config, so that we pass this responsibility off to the plugins themselves. That way, we can arbitrarily add new plugins to our graphql mesh, without having to update the base cli, runtime, and types packages each time. This gives us maximum modularity and the ability to write our own plugins if we need to. @Urigo what do think?
The text was updated successfully, but these errors were encountered:
There are times when the out-of-the-box plugins (i.e. transforms/handlers/etc.) aren't powerful enough to address a specific use case. The best option in these instances would be to use a custom-written plugin that allows its own custom config to be passed in. I've only been able to achieve this capability, however, by removing the
validateConfig(config);
statement fromparse-config.ts
in the runtime package.Since we currently generate a json schema at build-time and use that for validation, this prevents us from adding our own custom plugins with their custom configs. My recommendation to solve this would be to dynamically call a 'validateConfig()' method from each plugin when parsing the config, so that we pass this responsibility off to the plugins themselves. That way, we can arbitrarily add new plugins to our graphql mesh, without having to update the base
cli
,runtime
, andtypes
packages each time. This gives us maximum modularity and the ability to write our own plugins if we need to. @Urigo what do think?The text was updated successfully, but these errors were encountered: