elastic
Evaluate removing wildcard exports to improve tests startup time
Problem Statement
Wildcard exports in the main entry file (but also in other files in nested folders) cause tests to need to load and parse almost every file in the distribution package, upfront. Making it impossible to require only what's necessary.
wildcard re-exports by definition will have to eagerly load modules (fs read + parse + execute), which ends up being ~every file that EUI ships in its distribution
In numbers:
To quantify how much CPU is used:
- 800ms of Kibana startup (about 5%) is time being spent requiring EUI
- In each test file that ends up using EUI (which are 100s if not 1000s), it adds about the same delay to running the tests
What the wildcard exports look like in the main entry file:
// es/index.js
export * from './components';
export * from './services';
export * from './utils';
export * from './themes';
export * from './global_styling';
Proposed Solution
To remove all wildcard exports.
wildcard exports would have to be stripped everywhere
Possible ways to do it:
A) adding a compile step that will convert all wildcard exports and imports to named exports and imports, or B) writing a Babel plugin that will rewrite imports from the entry file to their source files?
A third option would be to manually remove them, making every single export explicit.
Related:
- https://github.com/elastic/kibana/pull/232076
Maybe good to clarify that A) would enable us in Kibana to defer requires by rewriting imports and exports using Babel. B) also entails a transform step, but doesn't require any other transformation in Kibana other than including the plugin that EUI provides.
Thank you for adding this issue. We've triaged it to determine priority and next steps:
- New status: Needs Decision
- Prioritization: We are treating this as a high priority and have added it to a list of candidates to consider for an upcoming planning session. This means we’re actively considering it, but it hasn’t yet been prioritized and scheduled.
- Next Steps: We’ll update here when we decide whether or not to prioritize it. In the meantime, please feel free to ping us here for an update.
Notes from our Triage session:
The team acknowledged that this is an important improvement that shouldn't be left to "die in the backlog."
We noted that there are likely "quick solutions" available. Both Weronica and Dario have some ideas on how to approach it. One suggested solution was a plugin that could automatically resolve deep imports for EUI components, similar to how lodash does it.
While it's not urgent enough to be worked on immediately, it was deemed too important to be left in the general backlog indefinitely.
@dgieselaar @acstll @weronikaolejniczak Are one of you able to explain in very basic terms, that a non-technical person could understand, what the value of solving this problem is?
It makes our jest tests faster. We currently spend about 16 hours on Jest tests in CI, a lot of them load EUI, and because EUI uses barrel files, a huge amount of JavaScript is read from disk, parsed and executed, including all the third party libraries that EUI imports.
So I assume it's a both a cost and time benefit.
Does anyone have a sense for how much of an improvement it would provide for cost or time?
I.e., We spend 16 hours today on Jest tests in CI, if we make this change it could be reduced to X hours and save X dollars.
Just looking for a ballpark.
And is the solution understood here? Like enough to put a ballpark estimate on this. Or is the next step like a time-boxed spike or something?
@JasonStoltz see https://elastic.slack.com/archives/C7QC1JV6F/p1758524430035419?thread_ts=1758524430.035419&cid=C7QC1JV6F.
Moved to blocked and added as "blocked by":
- https://github.com/elastic/kibana/issues/239462
@Ikuni17 is in charge of implementing the lazy requires. After that, we will be able to benchmark the real performance impact of:
- https://github.com/elastic/eui/pull/9119
There are a few export * left in that PR state. We'd need to update them before merging.
