Closed bmcconaghy closed 3 years ago
Pinging @elastic/kibana-stack-services
My only concern from switching from joi to kbn-config-schema, is how well exposed the latter is to customers vs joi. If it's not considered "public api", then how would customers create an action with it?
We're using both joi and kbn-config-schema currently in actions, so you can see both in action here:
joi for slack:
kbn-config-schema for email:
email has a lot more "config" than slack, so it's schema is neccessarily larger ...
It appears that kbn-action-schema is used for Kibana new platform plugins, so ... should be fine.
from @azasypkin:
At the moment when someone wants to create a NP plugin they don't have other choice other than using kbn/config-schema if they want to 1. define plugin config (the one that's read from yaml config), 2. define NP routes with schemas for query/payload/parameters. So I guess it's a part of "core public API".
Actions have been converted to schema-config via PR https://github.com/elastic/kibana/pull/40694
Need to convert alerts in a similar way.
we settled on config-schema
Convert existing uses of joi over to config-schema