Enforce camelCase format for a plugin id

[mshustov]

Summary

Closes #52190, #51226
Validates that pluginId set in camelCase.
configPath fallback to plugin id formated to snake_case automatically.
Adds requirements to the plugin manifest docs.

I added my concerns about the current implementation #52190 (comment)

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

• [ ] This was checked for cross-browser compatibility, including a check against IE11
• [ ] Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• [ ] Documentation was added for features that require explanation or tutorials
• [ ] Unit or functional tests were updated or added to match the most common scenarios
• [ ] This was checked for keyboard-only and screenreader accessibility

For maintainers

• This was checked for breaking API changes and was labeled appropriately
• This includes a feature addition or change that requires a release note and was labeled appropriately

Dev docs

When creating a new platform plugin, you need to make sure that pluginId declared in camelCase within kibana.json manifest file. It might not match pluginPath, which is recommended to be in snake_case format.

// ok
"pluginPath": ["foo"],
"id": "foo"
// ok
"pluginPath": "foo_bar",
"id": "fooBar"

[elasticmachine]

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

[mshustov]

@pgayvallet @joshdover updated the fallback mechanism to format pluginId to snake_case automatically, following the outcome of #52190
There are 2 plugins with id in camelCase that don't specify pluginPath: uiActions & advancedUiActions. Both of them don't use config, therefore they shouldn't be affected by the pluginPath auto-formatting.

[pgayvallet]

NIT: Maybe add an exemple myId => my_id

[mshustov]

@elasticmachine merge upstream

[mshustov]

@elasticmachine merge upstream

[mshustov]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 69aec7b

History

• 💚 Build #21051 succeeded 72dfdc6
• 💚 Build #20765 succeeded a47d2aa
• 💚 Build #20569 succeeded eb08294
• 💚 Build #19727 succeeded 8b689f3
• 💚 Build #18308 succeeded 43f9744

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[fbaligand]

So it means that an existing community plugin named “enhanced-table” has to change its id?
And so every plugin user has all his existing visualizations broken?

[VijayDoshi]

The warnings on startup are numerous, why is enforcement of camelCase useful here? I could be missing context so am happy to learn.

[pgayvallet]

@fbaligand This is currently only showing a warning. Post 8.0 this will probably be a requirement.

@VijayDoshi this is a subtask of enforcing some code/name conventions on plugins. See #52190 for context and reasons of this change.

[fbaligand]

Thanks for answer. Nice to see that real requirement won’t happen before 8.0.

I’m quite confused about the exact required name convention: is it enhancedTable or enhanced_table ?

[pgayvallet]

Plugin name should be camelCase and would be enhancedTable. As explained in #52190 the main reason for this is that plugin id is part of the plugin's contract, as it's this value that is used to retrieve a dependency plugin by it's id.

Associated default configuration path (if not explicitly specified in the plugin's kibana.json) would be enhanced_table (This is to ensure consistency with the ES stack's configuration properties naming conventions which uses snake_case for config files props)

[fbaligand]

Ok, thanks.