Kibana: Add support for UI-only plugins

[kimjoar]

Having UI-only plugins (plugins that don't include any server-side code) will in certain contexts, like Cloud, limit the "potential blast radius" of allowing users to upload third-party plugins.

We had a conversation with the part of @elastic/kibana-platform the other day and we agreed that it'd probably make sense to support plugins without server part. It's not difficult to add at this point and will require the following changes:

• Expect plugin server code only inside of plugin-dir/server/.... and client - plugin-dir/public/...
• Introduce optional server?: boolean property in plugin manifest
• Determine value of plugin.hasServerSide (name TBD) as typeof parsedManifest.server === 'boolean' ? parsedManifest.server : doesFolderExist('plugin-dir/server')
• Try to start plugin on the server side only if plugin.hasServerSide === true.

Previous issue description

It would be interesting to have some way to check before starting a plugin whether it contains a server part. Maybe just checking for the server directory is enough? Maybe the best approach is to include it in the plugin's package.json and add an integration tests that makes sure we never start a plugin that contains server side code if that flag is set? Maybe it's a CLI tool similar to the installer, that doesn't actually install but only reads and returns all the metadata about a plugin? Not sure, just throwing some ideas out there.

This might make more sense when we get rid of Webpack in production too, as these UI-only plugins would _only_ contain static files and Kibana wouldn't do anything else than require them in the UI.

[azasypkin]

Update description @elastic/kibana-platform. @epixa since you weren't presented at that discussion, would be great to have your input on that.

[azasypkin]

One thing that may be confusing is when UI-only plugin needs config, it will have to define server part just to be able to use it with the current architecture.

[epixa]

Rather than having the existence of a server directory influence a hasServerSide flag, we should throw an error and exit the process if you attempt to start Kibana with a plugin that indicates that it has server-side code but doesn't have necessary server-side code to initialize the plugin.

I'm not sure if we should even bother checking the directory paths. For one, the existence of a server directory doesn't mean the plugin works. With the manifest indicating that there is server-side code, no server directory, an empty directory, a module that doesn't export a bootstrap function, or a bootstrap function that doesn't return lifecycle contract are all examples of a broken plugin.

Other than that, this proposal sounds good to me.

[epixa]

Oh, and for configurations, I think it's totally fine for configurations to require server-side plugins. If something is UI-specific, an advanced setting would be a better place for it anyway. We do put some things in config today that are really only relevant on the client (e.g. tilemap configuration), but that'll change in time as we roll out the secret service.

[azasypkin]

Rather than having the existence of a server directory influence a hasServerSide flag, we should throw an error and exit the process if you attempt to start Kibana with a plugin that indicates that it has server-side code but doesn't have necessary server-side code to initialize the plugin.

That was one of the things I wanted to clarify as initially we were thinking about optional server: boolean that would imply some "heuristic" on our end (aka checking for server folder). You think if one wants the plugin to support server-side, setting server: true in manifest should be mandatory?

but that'll change in time as we roll out the secret service.

Ah, good to know!

[epixa]

You think if one wants the plugin to support server-side, setting server: true in manifest should be mandatory?

Yeah, let's treat the manifest as the source of truth for the things it does track. If we ever encounter a situation in the code that doesn't reflect what is described in the manifest, it should be an error scenario.