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
// This won't work if the plugin doesn't exist!import{FooSetup}from'../foo';interfacePluginDependencies{foo?: FooSetup}
...
setup(core,deps: PluginDependencies){if(deps.foo){// Foo is an optional dependency. If it's installed, do something with it.doSomething(deps.foo);}}
How can the Bar plugin use the correct types from the Foo plugin? Statically importing from an optional dependency will not work. One solution is for the Foo plugin to create another plugin that holds only the types, and that is required. This feels very hacky. Another option is that we recommend every plugin that is not required to create a separate type package.
Why is this becoming a problem now?
It's becoming a pattern to let OSS plugins take advantage of licensed functionality:
Runtime fields - The index pattern management plugin will expose runtime field capabilities if the runtime field plugin is installed. An alternative option is to build the field capabilities in such a way that they are extensible, however, this would require a larger architectural effort and it is debatable whether it would be a better architecture anyhow.
Reporting - Applications having knowledge of reporting capabilities. Applications will need to "opt-in" to reporting capabilities if the plugin exists. Applications are OSS, reporting is x-pack.
The text was updated successfully, but these errors were encountered:
Statically importing from an optional dependency will not work.
Types are only a build time concern because type-only imports are removed when creating the distributable, so I'm confused why this is the case. Can you give more information about why simply importing the type doesn't work? What error are you getting? Do you still get that error if you change the import to an import type statement?
I was able to create a new plugin that has an optional dependency on the existing spaces plugin, and everything seems to be working as expected locally. I created a PR with this plugin to run CI and make sure I wasn't missing anything: #88122
If the new plugin was to import static-code from the spaces plugin, it requires an additional requiredBundles: ["spaces"] entry in the kibana.json, but that's to be expected.
As it turns out, there was a bit of a miscommunication. Indeed, you can import types from optional dependencies. The confusion is because there is an eslint warning when attempting to import types from an x-pack plugin into OSS. If you override the lint warning, everything works.
We should probably remove the lint warning, and add documentation around code sharing (which I captured here #77958).
Our plugin system allows optional dependencies. A plugin could do something like this:
kibana.json:
How can the Bar plugin use the correct types from the Foo plugin? Statically importing from an optional dependency will not work. One solution is for the Foo plugin to create another plugin that holds only the types, and that is required. This feels very hacky. Another option is that we recommend every plugin that is not required to create a separate type package.
Why is this becoming a problem now?
It's becoming a pattern to let OSS plugins take advantage of licensed functionality:
Runtime fields - The index pattern management plugin will expose runtime field capabilities if the runtime field plugin is installed. An alternative option is to build the field capabilities in such a way that they are extensible, however, this would require a larger architectural effort and it is debatable whether it would be a better architecture anyhow.
Reporting - Applications having knowledge of reporting capabilities. Applications will need to "opt-in" to reporting capabilities if the plugin exists. Applications are OSS, reporting is x-pack.
The text was updated successfully, but these errors were encountered: