-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Plugins Discovery] Enforce camelCase plugin IDs #90752
[Plugins Discovery] Enforce camelCase plugin IDs #90752
Conversation
d538022
to
f4d3afa
Compare
f4d3afa
to
fcac06d
Compare
⏳ Build in-progress, with failures
Failed CI Steps
History
To update your PR or re-run it, just comment with: |
@elasticmachine merge upstream |
Pinging @elastic/kibana-core (Team:Core) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes in OIDC/SAML/UI caps fixture plugins LGTM.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alerting changes LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Security Solution changes, LGTM thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. re-requested a review to make sure we are only validating camelCase for plugins in src
and x-pack
. We dont want to be throwing errors for custom plugins; We'd be breaking a lot of external plugins if we do that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: We need to update the examples in the docs we give for migrating legacy plugins to the Kibana Platform. The example uses an id that's not camel case but it's not snake case either, however, if the example plugin id was changed to demoPlugin
from demoplugin
, it gives a great starting point for folks who tend to copy-paste
.
Code LGTM.
if (!packageInfo.dist && !isCamelCase(manifest.id)) { | ||
log.warn(`Expect plugin "id" in camelCase, but found: ${manifest.id}`); | ||
if (!isCamelCase(manifest.id)) { | ||
throw PluginDiscoveryError.invalidManifest( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR doesn't have an associated issue with it and it's a little difficult to determine why we're enforcing camel case now when we didn't originally. If we're wrapping up the platform migration work (we had to be more lenient while plugins were still migrating over), then changing from a log warning to an explicit error makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right! And I couldn't find an issue stating the reasoning behind this. The only thing I could find is the documentation about the Manifest file. It claims "Identifier of the plugin. Must be a string in camelCase. Part of a plugin public contract. Other plugins leverage it to access plugin API, navigate to the plugin, etc.".
I also found that the plugin-generator already creates the id as camelCased:
"id": "<%= camelCase(name) %>", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've requested a re-review to make sure we are only validating camelCase for plugins in src
and x-pack
. We dont want to be throwing errors for custom plugins; We'd be breaking a lot of external plugins if we do that.
Thank you all for your reviews! 🧡 @TinaHeiligers I'll update the docs straight-away! @Bamieh I did raise that question internally about considering these breaking changes, the answer was "plugins have never been declared as a public API. they aren’t subject to semver". Maybe we can flag them as breaking changes in the release notes but still ship it in a minor because the workaround requires very minimal changes? What do you think? cc @restrry UPDATE: The plugin-generator already creates the IDs as camelCased, and the documentation about the Manifest file claims it must be camelCased. Ideally, this shouldn't generate too much of an issue to third-party plugins if they used the tool and/or read the docs.
|
Yea, plugin API is not even considered experimental or beta yet (even if we really should consider doing that in 8.0 imho) And I even think it's better to do that 'breaking' change sooner than later, as the longer we wait, the more 3rd plugins we will break with that change.
I think flagging this as |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for clarifying. had to ask :) LGTM
I've created #91124 to handle the doc changes on a separate issue. It looks to me like updating the docs does not only need us to change the name but also the paths and HTTP routes to be fully compliant with our STYLEGUIDE. |
Co-authored-by: Kibana Machine <[email protected]>
Co-authored-by: Kibana Machine <[email protected]>
@afharo For the script to pick up this PR for the API changes doc, you need to use "Dev Docs" instead of "Release Notes" in the summary. I updated the summary. |
💔 Build Failed
Failed CI StepsTest FailuresKibana Pipeline / general / Chrome X-Pack UI Functional Tests.x-pack/test/functional/apps/cross_cluster_replication/feature_controls/ccr_security·ts.Cross Cluster Replication app feature controls security global all privileges (aka kibana_admin) should not render the "Data" sectionStandard Out
Stack Trace
Kibana Pipeline / general / X-Pack Accessibility Tests.x-pack/test/accessibility/apps/search_profiler·ts.Accessibility Search Profiler Editor click on the view details linkStandard Out
Stack Trace
Kibana Pipeline / general / X-Pack API Integration Tests.x-pack/test/api_integration/apis/ml/modules/setup_module·ts.apis Machine Learning modules module setup sets up module data for logs_ui_categories with prefix, startDatafeed true and estimateModelMemory trueStandard Out
Stack Trace
Metrics [docs]
History
To update your PR or re-run it, just comment with: |
@gchaps noted! I'll use it right next time. Sorry for the confusion. |
Summary
This PR enforces all the plugins' IDs to be camelCase (from warning to actual error) and changes all the test plugins that were not fulfilling this rule.
Checklist
Delete any items that are not applicable to this PR.
For maintainers
Dev Docs
Plugins' IDs in the
kibana.json
manifest must be camelCased. It has always been a requirement in the Kibana Platform but, up until now, Kibana only logged the deprecation warning. Now it refuses to start.