[kibanaReact] Reduce page load bundle to under 100kB

[tylersmalley]

For details, refer to the meta issue at #95853

The kibanaReact plugin is currently 118,239 bytes. To consider this issue closed, the limits.yml should be updated with the value under 100000.

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)

[streamich]

This needs discussion on how to approach it. App Services team is the main maintainer of the kibana_utils plugin, but not all code there is directly maintained by us. It is like a kitchen sink for React utility code.

Possible solutions would be:

• We create "utils" plugins for each team separately, in their domain, e.g. kibana_app/react.
• Or we allow deep imports from kibana_react plugin, so that other teams can only import what they need (but that would not work with our current .js bundling way, where each plugin is its own whole bundle).

[tylersmalley]

Related: #95866 (comment)

[Dosant]

This is the current state of an initial bundle of kibanaReact:

Most of these are components that don't have a dependency on other Kibana parts. We can code split those in two ways:

1. Add a Lazy wrapper for each component and export only them on plugin contract. Similar how we do with Markdown: https://github.com/elastic/kibana/blob/master/src/plugins/kibana_react/public/markdown/index.tsx
2. Move each component into a separate package. This way other plugins can import components into their async chunks.

I think exporting those into a package is preferable because it will allow consumers to import components directly into their async chunks and control the loading state how they prefer. I think will also produce less boilerplate code than a lazy wrapper inside a plugin approach.

I think in general it makes sense to leave in kibana_react only what has a dependency on other plugins or core. e.g. RedirectAppLinks helper

@elastic/kibana-operations, could you please review this ^^, does it make sense, or are there other nuances?
Q1: Does it have to be a separate package for each component or is it possible to have multiple entry points for a package? Do we have such examples? Looks like i18n/react is a good example
e.g.:

import { A } from '@kbn/page_template/no_data_page';
import { B } from '@kbn/page_template/nav';

Q2: Are there any caveats with scss import into a package? I bumped into this and looks like package needs some additional styles processing setup

[spalger]

@Dosant I totally agree that we should break these into little packages. There are going to be some hurdles to gettin this work but I hope that my PR against #114129 resolves most of them, and that we can use that as a blueprint for the rest of the packages.

Please let us help you get this broken into packages, it's the way we hope most of this will go in the future.