Hi, I want to start a conversation around forking EUI. which I believe will eventually happen soon.
One of the decisions to make is whether we will add it to OpenSearch-Dashboards or as its own project.
Originally EUI was in Kibana, and as it grew larger and served more projects, Elastic decided to split it into its own project.
The benefits I see in having it as a separate project. (add if you thing or know otherwise):
Its easier to introduce new developers to the code because the project is smaller and requires less knowledge over the intricacies of OSD
it’s easier to separate concerns and coupling between style and functionality, making components less biased towards a certain feature.
currently, most changes requires several actions, like: the change itself, tests, storybook update ( documentation ), changelog, having all these changes in the OSD project is just a lot of noise.
The EUI will indeed serve only OSD at this point, but I believe it will demand outside the project as OpenSearch gets adopted, more and more projects would want to match their styling. Even developing plugins or landing pages in a separate environment and handling imports would be nicer If you could do so separately.
easier to follow and label issues between the components
there a specific automation that we can add ( like screenshotting tests ) that will just bloat the project
EUI is no small project, over 500MB now.
On the other hand,
It will be easier to maintain inside OSD, not having to split your PRs between two projects to when updating a component or a feature is nice to have.
I would be in favour of keeping it separate, I think it is likely to be used without the rest of OpenSearch Dashboards sometimes, so let’s make that path easy for users, even if it means a bit more co-ordination work on the maintainer’s side.
Its easier to introduce new developers to the code because the project is smaller and requires less knowledge over the intricacies of OSD
I feel like this a big component of it of why it should be a separate project. Also, OSD is a big project to maintain and might take time to review and build in whereas if it was separated then the work can be done asynchronously.
I would also lean towards it having separate repo for both charts / EUI, as they themselves are big project and more closely attached to UX compared to Dashboards. This could help everyone to innovate independently and move faster. It will also easy for community members to contribute only for EUI / Charts without worrying about the knowing how dashboards works.
On other side, If we prefer mono-repo, I think we should consider everything to be mono-repo and not just this so our decision on how we decide to do the repository organization should be followed for rest of way as well.
Right now, OpenSearch Dashboards is the only product in the project that uses EUI or Charts. Is there somebody in the community who has bigger ambitions for one or the other of those and would want to step up to maintain and advance a standalone fork?
Realistically there some be some kind of vote by the community. Obviously since you work for AWS and this is an AWS project you can on theory do whatever you want to do, which is kind of the problem with the OpenSearch community at this time.
I think we have seen from this thread people prefer to keep it split out, which is also why Elastic did what they did, so undoing that might not be proudent.
To create and develop a fork of EUI/Charts would certainly take some time and effort - rebranding, generalizing, advancing, promoting, etc. That could be a modest-to-medium investment, or could be a large investment, based on how grand a maintainer’s aspirations are for this design system. So I think “voting” around a question like this takes the form of somebody raising their hand and and saying “hey, I’d love to do that!”
As a project, we’d be super excited to support anybody who wanted to create a broadly-useable design system based off of open source EUI, whether that be by hosting it in the project github org, adopting it for OpenSearch Dashboards, helping with testing & CI/CD, helping promote it, you name it. Make a proposal and let’s talk.
I also favour forking it into its own repo. My reasons are more for the future than right now. Eui is currently available as a npm package. This makes it easy for a plugin developer to use the same components OpenSearch Dashboards uses to be available to them to customize their plugins without the need to build their own. Currently this is not needed since plugin development happens directly inside OpenSearch Dashboards code. Keeping it separate will allow OpenSearch in future to let plugin development to happen outside the Dashboards codebase, reducing the barrier to entry.
This is similar to the approach other OOS projects have taken, e.g. Grafana (See video description)
In principle, I (personally) don’t have a problem with this, although I’m certainly not the prime stakeholder here.
There are some folks that are more directly involved that don’t follow every message on this board. Let me surface it with them and figure out where best to have the conversation about the first steps in the open.
OK. Let’s start with an issue on OpenSearch-Dashboards about EUI before we do the PR. It’ll give everyone a chance to discuss procedural bits about forking before throwing down code. Sound good?
Updated the issue… Seems like the decision here is the move it into the opensearch dashboards codebase, which seems fine to me. We just have to determine the impact to the builds and such. We will open a PR when the AWS team is ready and ensure it works properly.