-
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
Visualizations Plugin -> New Platform Ready #44644
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 |
@@ -24,7 +24,7 @@ import { i18n } from '@kbn/i18n'; | |||
|
|||
import chrome from 'ui/chrome'; | |||
import { VisType } from 'ui/vis'; | |||
import { VisTypeAlias } from 'plugins/visualizations'; | |||
import { VisTypeAlias } from 'src/legacy/core_plugins/visualizations/public/np_ready/public'; |
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 matthew.kime@elastic.co 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
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.
@@ -30,11 +30,13 @@ import { SavedObjectsClientProvider } from 'ui/saved_objects'; | |||
import { VisualizeListingTable } from './visualize_listing_table'; | |||
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
visualizations
plugin incore_plugins/visualizations
/core_plugins/visualizations/public/np_ready/
folder.np_ready
folder.kibana.json
manifestindex.ts
plugin.ts
legacy.ts
mocks.ts
__LEGACY
object..types.registerVisualization()
instead of.types.VisTypesRegistryProvider.register()
insetup
contract.Parent issue: #44121
Dev Docs
plugins/visualizations => src/legacy/core_plugins/visualizations/public/np_ready/public/