[Meta] Environments/Projects we want to intentionally support

[chandlerprall]

trafficstars

We've talked a lot about which projects & environments we want to support. I'm rolling those up into this ticket as a place to track discussions & decisions.

External (non-Elastic) targets mean we intend to support EUI running in those environments, Internal (Elastic managed) targets likely means we directly maintain & update as EUI releases.

Current targets

• EUI Gatsby starter (https://github.com/elastic/gatsby-eui-starter)
• codesandbox
• Create React App

Possibilities

• EUI Next.js starter (https://github.com/elastic/next-eui-starter)
• Server Side Rendering (#2074)
• ESM-only systems such as snowpack and vite (#3521)

Acceptance criteria

Automated testing for projects and deployments that we expect EUI to support. Currently, we rely on manual build steps or testing suites (functional and/or unit tests) provided by consuming applications to check environment compatibility and catch instances of breaking API changes. Conversion to and adoption of TypeScript has helped at a low level, but we need broader, less manual means of understanding support coverage.

Outcome A script or pattern of scripts that EUI engineers can run to:

1. Install EUI in various project target instances; #2760 tracks the discussion about which projects to support.
2. Run the consuming project's linting and / or testing suite(s).
3. Run a production build of the consuming project.
4. Detect and report failures and incompatibilities.

[legrego]

If you're accepting unsolicited feedback, I'm fond of the codesandbox target. I find this especially useful when submitting small reproductions for EUI issues, or when trying to isolate behaviors between Kibana and EUI. Codesandbox allows me to get an environment quickly spun up without having to manage another project or toolkit on my own machine.

[snide]

@legrego Have a gander at https://github.com/elastic/eui/pull/2728

😄

Has one issue with icons, but otherwise builds dynamic sandboxes for most examples in our docs.

[jshreyans]

@chandlerprall could you elaborate a little more on the create react app point. This is in the context of the testing suite that we aim to develop for various environments. How does create react app add any difference to the testing suite? It is essentially just a bootstrapping tool and does not add any special functionality to the project. The project is basically just a simple React app and can be tested like one, using conventional methods.

[chandlerprall]

@jshreyans you're correct; the create react app target would be more of a smoke test that EUI compiled correctly and is usable. As an example, I've used it to verify TypeScript changes don't introduce any breaking changes, or that we've added a dependency correctly.

It wouldn't necessarily need to be create react app, but that was a quick way to describe exactly what you said: just a simple React app - and one that wouldn't need extra configuration to get setup.

[jshreyans]

It wouldn't necessarily need to be create react app, but that was a quick way to describe exactly what you said: just a simple React app - and one that wouldn't need extra configuration to get setup.

Great thanks a lot!

[PeterSenpai]

From what I see, this test is essentially a sanity test to verify if the external and internal packages can install EUI(npm link) package, and then run build, lint successfully. I am thinking about if we can use scripts to add some code to actually use the EUI and then run build etc for better testing.

[JasonStoltz]

@elastic/eui-design How would ya'll feel about closing this Meta Issues and capturing the current state in our README? What is the current state? We can be explicit about what is supported and unsupported:

Supported EUI Gatsby starter (https://github.com/elastic/gatsby-eui-starter) codesandbox -- What does support look like, is there a template somewhere? Create React App -- What does support look like, is there a template somewhere? EUI Next.js starter (https://github.com/elastic/next-eui-starter)

Unsupported Server Side Rendering (https://github.com/elastic/eui/issues/2074) ESM-only systems such as snowpack and vite (https://github.com/elastic/eui/issues/3521)

Edit: How would ya'll feel about deprecating our Gatsby starter? What about our Next starter? I'm just wondering out loud if there is enough value there vs the effort to maintain them.

[cee-chen]

1. Gatsby Starter - I would be ++ for deprecating this personally.

2. Next.js starter - I strongly think we need to support this as multiple Elastic projects (EUI+, Docsmobile) are using Next.js. I also think this support goes hand-in-hand with SSR, since Next.js supports SSR and docsmobile I believe uses SSR (we should check with @glitteringkatie to confirm)

3. Create React App - I think we should keep support for this. There isn't a template for it but I've spun up very quick CRA's with Elastic in the past and usage is as basic as running npx create-react-app and then following all the installs and App.js setup steps listed in https://elastic.github.io/eui/#/guidelines/getting-started. It's one of the most basic smoke tests possible

4. CodeSandbox - uhh, I mean all our demos are in this so I would personally vote for keeping it. It's also a really easy way for people to get us minimum reproducible issues. It seems like a bit of a freebie.

5. SSR - I think we need to dedicate more dev time to supporting this. See next.js above

6. Vite, rollup, etc. - I also think we need to dedicate more dev time to supporting this. ESM is definitely the way JS is going and we're going to get left behind if we ignore modern bundlers.

Honestly, the major issues with SSR and Vite are all around either our icons (which use dynamic imports - https://github.com/elastic/eui/issues/5463), or Emotion's cache/flash of unstyled content, so if we fix that, we're like 90% of the way there.

[1Copenut]

I agree with @cee-chen about SSR && Vite.

[andreadelrio]

1. Gatsby Starter - I would be ++ for deprecating this personally.
2. Next.js starter - I strongly think we need to support this as multiple Elastic projects (EUI+, Docsmobile) are using Next.js. I also think this support goes hand-in-hand with SSR, since Next.js supports SSR and docsmobile I believe uses SSR (we should check with @glitteringkatie to confirm)

Just to add a +1 to this and to mention that a few of us designers are currently using the Next.js starter to do code prototypes.

[JasonStoltz]

Just to add a +1 to this and to mention that a few of us designers are currently using the Next.js starter to do code prototypes.

Good to know! Glad folks are getting use out of it.

[cee-chen]

I was cleaning up our docs and also wanted to mention this as "environments we support":

our build targets [are] ES5+commonjs, ES5+ES Modules, and a consolidated bundle file.

At some point, do we want to move away from commonjs support and consider moving only to ESM? This is something, e.g. unified and refractor has done: https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c

It would likely simplify as well as lower our release/build times/sizes, given that Kibana can support ESM.

[cee-chen]

Vite support

Adding a comment dedicated to tracking reported Vite issues. It looks like ESM only produces problems with our common-js dependencies, so support may be more of a dev lift than originally thought:

• https://github.com/elastic/eui/issues/6616
• https://github.com/elastic/eui/issues/6635
• https://github.com/elastic/eui/issues/5463
• https://github.com/elastic/eui/issues/3521

SSR support

• https://github.com/elastic/eui/issues/5419

[JasonStoltz]

As this issue is just about 4 years old and the thinking on this issue has shifted over time, I thought I'd try to roll up all of the comments into an updated issue that reflects our current thinking in 2024. To that end, this conversation can now be followed in https://github.com/elastic/eui/issues/7630.