-
Notifications
You must be signed in to change notification settings - Fork 8.5k
Visualizations Plugin -> New Platform Ready #44644
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
Conversation
|
Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually? |
|
retest |
💔 Build Failed |
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 think this would make more sense as a relative path. There are a couple of other references like this in this PR.
I believe np_ready can go directly into visualizations
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.
As #44306 said to create np_ready folder, I did so. But I also thought that it wasn't necessary because visualizations plugin doesn't have any legacy code right now.
I'll revert it back to the first non-np_raedy version.
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.
After investigating a bit, I found out that np_ready cannot be removed.
As visualizations lives in legacy/core_plugins it needs to have package.json and index.ts files for legacy plugin initialization.
When we remove them, we should merge legacy index.ts and np index.ts.
It seems that np_ready is necessary evil for now.
p.s. I've changed all paths to relative in the below.
|
Hello @sainthkh - it looks like you've picked up an issue that was part of our release planning process. Thank you! I'm looking forward to working with you to get this PR into our codebase. That said, because this was part of our planning process its also considered critical path for our 7.5 release. We should talk to make sure that our interest and commitment levels align so both sides are happy with how things proceed. Drop me an email at [email protected] and we'll talk through the details of working together. |
|
@mattkime I sent you an email. |
a00bf58 to
2d879d9
Compare
|
Done. Ready for test and review. |
|
Pinging @elastic/kibana-app-arch |
|
LGTM - checking on whether this needs release notes. if so I'll write them. |
|
jenkins, test this |
💚 Build Succeeded |
* Created np_ready/public and moved files into it. * Added kibana.json * Added plugin.ts and moved plugin class into it. * Added legacy.ts and moved ui imports to legacy.ts. * Added mock.ts * Created registerVisualization() and removed VisTypesRegistryProvider from setup(). * Fixed imports from plugins/visualizations. * Removed visualizations from index.ts and call setup directly from legacy.ts
lukeelmers
left a comment
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 know this has already merged, but I had a few comments that I think we should address -- I will make a follow-up PR with some adjustments.
| import { NewVisModal } from '../wizard/new_vis_modal'; | ||
| import { VisualizeConstants } from '../visualize_constants'; | ||
| import { visualizations } from 'plugins/visualizations'; | ||
| import { setup } from '../../../../visualizations/public/np_ready/public/legacy'; |
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 think we should be exporting this contract from the top level public instead, e.g. visualizations/public/legacy
np_ready directory is an implementation detail of the visualizations plugin and consumers of this shim shouldn't need to be aware of whether the directory exists or not.
also (nit) for clarity I think it's nice to do import { setup as visualizations } or setup as visualizationsSetup or similar as we have done elsewhere... would be good to make this consistent across the PR
* Created np_ready/public and moved files into it. * Added kibana.json * Added plugin.ts and moved plugin class into it. * Added legacy.ts and moved ui imports to legacy.ts. * Added mock.ts * Created registerVisualization() and removed VisTypesRegistryProvider from setup(). * Fixed imports from plugins/visualizations. * Removed visualizations from index.ts and call setup directly from legacy.ts
Summary
Fixes #44306.
Setup NP-ready folder for
visualizationsplugin incore_plugins/visualizations/core_plugins/visualizations/public/np_ready/folder.np_readyfolder.kibana.jsonmanifestindex.tsplugin.tslegacy.tsmocks.ts__LEGACYobject..types.registerVisualization()instead of.types.VisTypesRegistryProvider.register()insetupcontract.Parent issue: #44121
Dev Docs
plugins/visualizations => src/legacy/core_plugins/visualizations/public/np_ready/public/