[DISCUSS] Forking EUI and Charts into new repo or existing codebase

[jkowall]

As per https://discuss.opendistrocommunity.dev/t/talk-about-opensearch-ui/6319/15 we would like to determine the path forward for EUI. The project is no longer open source, so we'd need to fork the last version which seems to be: previous to this PR elastic/eui#4930

Since we would like to begin work on skinning this decision needs to be made sooner than later. This will make it easier for us to apply themes to the UI.

There are many good arguments for keeping EUI separate, but also some for incorporating it in.

• EUI is typically not used outside of Kibana, but it could in theory be used for that. I do not see this as a use case for this project.
• From the perspective of my employer, we use a couple of the controls from EUI inside other parts of our product, but we can do this without EUI being separated out.
• EUI would have to be released with each release of OpenSearch Dashboards which would mean unnecessary code being cut more regularly.

Continue the discussion.

[stockholmux]

@elfisher you might be interested.

[jkowall]

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.

[jcgraybill]

Pulling an Apache-2.0-licensed fork of EUI into the OpenSearch Dashboards codebase looks looks like the lowest-effort approach to meet the current need, so I think that one is effectively the de-facto default choice. Let's keep the issue open for a few more days, though, to give more stakeholders a chance to weigh in.

[kavilla]

I'm on the side of forking into a new repo but I think the forum and comments here raise some good points. The work upfront will be the lowest effort especially related to publishing builds.

I think now it can be merged into an existing repo to solve our issues now but in the future make it into a new repo? The codebase is so large already and uninviting to develop in plus it would nice to have a separation of concerns.

[seanneumann]

This is a two-way door. Let's move it into the Dashboards codebase. Down the road if there is a strong case to pull it out into a separate repo, we can do it then.

[JacobBrandt]

Consensus seems to move EUI into the same repo so I'm assuming https://github.com/elastic/elastic-charts will as well. Is that correct?

[elfisher]

Consensus seems to move EUI into the same repo so I'm assuming https://github.com/elastic/elastic-charts will as well. Is that correct?

@seanneumann, charts is also going to get moved in like EUI, right?

[seanneumann]

@CEHENKLE will drive this discussion, but it probably makes sense to keep EUI/Charts in the Dashboards repo.

[CEHENKLE]

Yup, we are cutting a separate issue for Charts. We'll update here once that issue is up :)

[seanneumann]

@CEHENKLE after more discussion, we are thinking we can combine the effort. We'll comment on the approach and request comments shortly.

[AMoo-Miki]

I have filed an RFC, #695, with the options I considered for Charts and EUI, along with a proposal. I would like your feedback.

[CEHENKLE]

@jkowall Hey Jonah! I wanted to make sure you saw #695. I'm really looking forward to hearing your thoughts.

Thanks!
/C

[jkowall]

Looks like a good plan to me. I would like @galangel as more of an expert to comment on it as well. He is reviewing.

[seanneumann]

The latest conversations are that we'd like to fork EUI and rename it to OpenSearch Design System.

[seanneumann]

OpenSearch Design System - what will the shorthand be? This will important to the renaming effort.

[kavilla]

OpenSearch Design System - what will the shorthand be? This will important to the renaming effort.

I have created a parent issue for forking: #1766
And a discuss on the shorthand here: opensearch-project/oui#2

Will close this issue.