Chore: UI Framework Package#13819
Conversation
in the readme and the link to the code in the repo
move to the root, and break out the base config parts so we can reuse it for the dist build
|
Thanks for doing this! I haven't looked at the code but based on your description this sounds like a great improvement. I'm looking forward to dedicating some time to helping you move this forward when I'm off paternity leave. |
|
Removing me as a reviewer for now. @cjcenizal: Just ping me when you're back and ready to discuss this PoC and how we can move it forward in a way that works nicely with the new platform. |
|
I'm 100% behind moving the UI framework out of Kibana and installing it as a dependency. Design would love to have a single source of constants for UI that spreads across our various projects and can be extended upon. FWIW I'd love to have a lighter shell for the build process, since it's a little slow currently with all the webpack stuff. Right now it's still a few seconds for a css build, which can be improved. |
|
@cjcenizal @snide Is this still something you guys are interested in? I realize a lot is still in flux with the framework, and again, I don't expect this PR to actually be merged, but I'm curious if this is still an end goal for you. Also, I was talking with @bevacqua and he expressed an interest in being able to use the framework without Kibana, so that we can make other properties look and function consistently, and this would be a step in that direction. |
|
@w33ble https://github.com/elastic/eui I still need to port over some of loose PRs, but the cloud team moved it out last week. |
|
@w33ble FYI this is what we ended up with: https://github.com/elastic/eui, we're already using it in a PR that's coming to Cloud not too far in the future: https://github.com/elastic/cloud/pull/8868 (Still very much a WIP, but moving quickly) |
|
@w33ble I think the end goal is to depend on the EUI repo the way Cloud is, but I don't think we can do that until we have a clearer idea of how we're going to change Kibana to use the K7 components. So with this new info in mind, will making this kind of change provide us any benefits? I wonder if it's still worth the effort. |
It sounds like you guys have a better path forward, which is great! I'm going to close this PR. Thanks for the update. |

The idea of a monorepo has been floated around a bunch, and we already have some stuff in
packagesalong that goal. Also, it's always bothered me that the UI Framework is just kind of dumped into the Kibana root, so I wanted to see what it would take to move the ui_framework intopackagesand treat it as its own thing. Perhaps unsurprisingly, it didn't take much.All the existing grunt tasks were converted to simple npm scripts, and all the dependencies were plucked out into their own
package.json. I added an independent build step to create a js and css dist, but that's more for experimentation than something I think we need.I did not take the time to clean the ui_framework stuff out of core (tasks, dependencies), as this is more PoC than anything. I also don't know how the ui_framework is built into core, and couldn't easily figure that out, so I didn't try to replicate that part.
I don't really expect this to get merged. You can discuss it, close it, whatever. I just thought I'd share what this could look like moved into
packagesand treated as its own project.