Document and enforce camelCase plugin id format

[mshustov]

The legacy plugin system uses a convention that plugin id should be in snake_case. All public API provided via hapi plugin system followed this convention
In legacy platform plugin public contract looks like:

// plugins/my_plugin/index.js
new kibana.Plugin({
  id: 'my_plugin',
  require: ['another_plugin']
});
// later in code
server.plugins.another_plugin.get()

Although on the client side plugins can register an angular directive or export API under any name, usually in camelCase.

In New platform, we should formalize the requirement for id format, because it's the part of the plugin public contract.
Dependent plugins use it:

• to declare a dependency on a plugin

"requiredPlugins": ["another_plugin"]

• to access dependency API

setup(core, deps){
  deps.another_plugin.get() // can be passed deeper down the tree

• interact with plugins

apps.navigateToApp('another_plugin')

Since id became a first-class citizen in the app codes, shouldn't we review our requirement and enforce the camelCase format for it?

We can add runtime check in discovery to enforce this rule.

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[stacey-gammon]

+1 to camelCase!

[pgayvallet]

If we choose to go with camel, should the plugin's folder follows this rule too?

[mshustov]

@pgayvallet we cannot. We've already got a filename convention https://github.com/elastic/kibana/blob/master/STYLEGUIDE.md#filenames
It's quite often that plugin folder name and id are different in the legacy platform
https://github.com/elastic/kibana/tree/master/src/legacy/core_plugins/vis_type_markdown
https://github.com/elastic/kibana/tree/master/x-pack/legacy/plugins/cross_cluster_replication

[pgayvallet]

+1 to camelCase then

deps.anotherPlugin.get() feels way better than deps.another_plugin.get()

[joshdover]

+1 to camelCase as well

[joshdover]

Going with camelCase. Need documentation and runtime validation of camelCase.

[mshustov]

As we decided to go with #46705 the proposed change will create a mismatch between pluginId fooBar and configPath foo_bar. Now every plugin in camelCase has to define configPath explicitly.

// kibana.json
"configPath": ["foo_bar"],
"id": "fooBar"
// kibana.yml
foo_bar.baz: 42

If configPath not specified explicitly, the platform will use the pluginId to access the config.
Do we want to convert pluginId from camelCase to snake_case reading the config to enforce snake_case convention for the config values?. I'd rather avoid this, because it worsens the code predictability. That being said, this is okay:

// kibana.json
"id": "fooBar"
// kibana.yml
fooBar.baz: 42

Otherwise it will be

// kibana.json
"id": "fooBar"
// kibana.yml
foo_bar.baz: 42

[pgayvallet]

As we want to go away from camelCase in configuration in #46705, I'm afraid letting fooBar.baz as the default for the fooBar plugin might not be something we want. I agree automatic conversion to foo_bar is not ideal, However this is still a predictable and bijective (at least I think for the bijection?) transformation, so that might be the way to go?

[joshdover]

I think we should have good defaults here so that plugins don't have to specify configPath manually in most cases.

I don't think the risks of auto-converting the plugin ID to get the the default configPath are very high, but should definitely be documented well. I don't think we should auto-convert the configPath if it is explicitly set though.

// kibana,json
"id": "fooBar"
// kibana.yml
foo_bar.baz: 42

As an aside, it'd be nice if xpack plugins didn't have to specify a configPath manually, but that's a separate issue.