Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discuss] How to use types from optional dependencies #88017

Closed
stacey-gammon opened this issue Jan 12, 2021 · 4 comments
Closed

[Discuss] How to use types from optional dependencies #88017

stacey-gammon opened this issue Jan 12, 2021 · 4 comments
Labels
discuss Team:Operations Team label for Operations Team

Comments

@stacey-gammon
Copy link
Contributor

Our plugin system allows optional dependencies. A plugin could do something like this:

kibana.json:

{
  "id": "bar",
  "optionalPlugins": ["foo"],
  "server": true,
  "ui": true
}
// This won't work if the plugin doesn't exist!
import { FooSetup } from '../foo';

interface PluginDependencies {
   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.

@stacey-gammon stacey-gammon added discuss Team:Operations Team label for Operations Team labels Jan 12, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-operations (Team:Operations)

@spalger
Copy link
Contributor

spalger commented Jan 12, 2021

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?

@kobelb
Copy link
Contributor

kobelb commented Jan 13, 2021

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.

@stacey-gammon
Copy link
Contributor Author

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).

Sorry for the confusion!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss Team:Operations Team label for Operations Team
Projects
None yet
Development

No branches or pull requests

4 participants