Plugin API changes in 7.14
editPlugin API changes in 7.14
editThis page discusses the plugin API changes that you need to be aware of when migrating your application to Kibana 7.14.
Other versions: 7.13 | 7.12 | 7.11 | 7.10 | 7.9 | 7.8
Security plugin return types improved
__legacy
and sessionTimeout
were removed from the Security plugin’s setup contract:
-
Changed to explicit interfaces instead of
ReturnType<X>
as recommended in the Developer Guide. Improved the API docs and supports comments. -
Removed
__legacy
return from theSetup
function because it was unused. -
Removed
sessionTimeout
return from theSetup
function because it was also unused. - Added comments.
Refer to #101492.
URL locators introduced as part of the URL Service
URL generators are now deprecated. Instead, create a generator for deep links in Kibana using locators in the URL Service.
Deep link providers
Before you created a URL generator, like so:
plugins.share.urlGenerators.registerUrlGenerator(/* ... */);
Now you create a "locator":
plugins.share.url.locators.create(/* ... */);
Deep link consumers
Before you used a URL generator to get a relative deep link in Kibana:
plugins.share.urlGenerators.getUrlGenerator('MY_GENERATOR').createUrl(/* ... */);
Now you create a relative link, or navigate immediately using locators:
plugins.share.locators.get('MY_LOCATOR')!.getLocation(/* ... */); plugins.share.locators.get('MY_LOCATOR')!.navigate(/* ... */);
Refer to #101045.
NodesVersionCompatibility
interface changed
The NodesVersionCompatibility
now includes an optional nodesInfroRequestError
parameter:
Before
export interface NodesVersionCompatibility { isCompatible: boolean; message?: string; incompatibleNodes: NodeInfo[]; warningNodes: NodeInfo[]; kibanaVersion: string; }
After
export interface NodesVersionCompatibility { isCompatible: boolean; message?: string; incompatibleNodes: NodeInfo[]; warningNodes: NodeInfo[]; kibanaVersion: string; nodesInfoRequestError?: Error // any error that's thrown from a call to `nodes.info` will surface here. }
If present, the error is also available on ElasticsearchStatusMeta
:
Before
export interface ElasticsearchStatusMeta { warningNodes: NodesVersionCompatibility['warningNodes']; incompatibleNodes: NodesVersionCompatibility['incompatibleNodes']; }
After
export interface ElasticsearchStatusMeta { warningNodes: NodesVersionCompatibility['warningNodes']; incompatibleNodes: NodesVersionCompatibility['incompatibleNodes']; nodesInfoRequestError?: NodesVersionCompatibility['nodesInfoRequestError']; }
Refer to #100005.
chrome.navLinks.update
API removed
The chrome.navLinks.update
API was replaced with the appUpdater
API.
Before
export class MyPlugin implements Plugin { setup({ application }) { application.register({ id: 'my-app', title: 'My App', async mount(params) { const { renderApp } = await import('./application'); return renderApp(params); }, }); } start() { // later, when the navlink needs to be updated chrome.navLinks.update('my-app', { hidden: true }); } }
After
export class MyPlugin implements Plugin { private appUpdater = new BehaviorSubject<AppUpdater>(() => ({})); setup({ application }) { application.register({ id: 'my-app', title: 'My App', updater$: this.appUpdater, async mount(params) { const { renderApp } = await import('./application'); return renderApp(params); }, }); } start() { // later, when the navlink needs to be updated appUpdater.next(() => ({ navLinkStatus: AppNavLinkStatus.disabled, })) } }
Refer to #99633.
Config objects no longer mutated during deprecations
When a plugin implements a custom deprecation function, it used to mutate the config object.
Now it returns either the set
command to extend config
or the unset
command
to remove the config
property. Refer to Command pattern.
Before
(config, path, addDeprecation) => { set(config, path, newValue); set(config, another_path); return config }
After
(config, path, addDeprecation) => { return { set: [{ key: path, value: newValue }], unset: [{ key: another_path }] } }
@kbn/config
doesn’t enforce config
runtime immutability,
but only compile-time check. It’s done to prevent cases when a deprecation
depends on another deprecation to be executed because
our test coverage cannot detect such cases.
You can do that manually in a follow-up if you think it’s worth the effort.
rename('foo.bar', 'foo.baz'), (config, path, addDeprecation) => { if(config.baz) { // ... }
Refer to #99629.
UI settings client API updated
The unused overrideLocalDefault
and getSaved$
methods were removed.
Refer to #98248.
Custom plugin status checks improved
Custom status checks registered by plugins on the core.status.set
API
must now emit a value within 30s or they will timeout to an unavailable
status.
Refer to #77965.