Context:

Our ultimate vision for Kibana development is that every piece of typescript code that we can isolate in a separate block could act as a ts project/package. That's why we started #80508 some months ago. As more and more projects are getting pushed in we started to feel a slow down when building the typescript project references during bootstrap. @spalger is trying to build a cache that we can use immediately but for the long term we would want to leverage Bazel to do that, we are just not there yet to do it today. Here are my findings as a result from a mini poc that I have been building over the last days after syncing on that matter with @tylersmalley:

Strategy on Bazel:

Currently we are relying on Typescript project references to be able to build types from our TS plugins to later use those. On Bazel our strategy will have to be different because Bazel runs everything on a sandbox and clearly separates the outputs from the workspace. Let's take src/core as a ts project to build with bazel and src/plugins/kibana_utils as a plugin that will be built using the bazel outputs for src/core. In order to do it, those are the required steps as of today:

• Create a BUILD.bazel file under src/core that will hold the Bazel rules to build that project.
• Change our tsconfig.base.json rootDirs so we can make typescript consider that our workspace, the bazel sandbox environment and the bazel output folder are all the same
• Create an absolute path key on tsconfig.base.json that points to src/core/*
• Change all the relative imports to src/core on src/plugins/kibana_utils to be src/core/....
• Remove src/core/tsconfig.json from the list of project references on src/plugins/kibana_utils as we will be treating src/core as we treat node_modules, as an external.
• Create an additional step on kbn bootstrap to run our Bazel build_ts_refs rules
• Done

We were able to get this mini poc to work at #91079. This work is at least blocked on migrating @kbn/analytics, @kbn/config-schema, @kbn/config, @kbn/dev-utils, @kbn/i18n, @kbn/legacy-logging, @kbn/std, @kbn/test-subj-selector, @kbn/test, @kbn/utility-types which are dependencies of src/core

Future Required Steps:

For now we will proceed with our current outlined phase 1 on the Bazel project defined at #69706 but we could be able to look at implementing our ideas listed above in the further phases (2 or 3). In order to do it I think our only identified blocker is to not have relative imports that crosses the packages boundaries. I would say we can start a discussion and outline a rollout plan for it as it will have to ask the solution teams to apply the required changes, defining what are the alias we want to use for the absolute imports as well as developer tooling we need to develop to helper in the transition and also to avoid future wrongly added relative imports (eslint probably).

\cc @restrry @joshdover as we discussed this on the yesterdays kibana developer experience sync meeting