Migrate Kibana plugins from TS project references into Bazel

[mistic]

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

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[elasticmachine]

Pinging @elastic/kibana-operations (Team:Operations)

[mshustov]

In order to do it I think our only identified blocker is to not have relative imports that crosses the packages boundaries.

I'm aware of at least a couple of places when Core depends on external modules:

• on cli Remove circular dependencies between CLI & core #76935
• data plugin [core.savedObjects] Update esKuery imports to pull from new package instead of data plugin #55485

How soon should it be fixed to unblock Core migration to Bazel?

[mistic]

@restrry we will probably get back to that task only after completing the phase 1 for the Bazel project. However I would say we should start the discussion about what to do and start the work to unblock as soon as we can \cc @tylersmalley

[mshustov]

we will probably get back to that task only after completing the phase 1 for the Bazel project.

@mistic @tylersmalley at least tentatively: by which release do we need to solve these problems?

[mistic]

I would say by 7.14. Am I right @tylersmalley ?

[joshdover]

I've opened #94141 to track any work that the Core teams needs to complete to support this effort. Please add anything that we're missing. Last I spoke with @tylersmalley, this phase was expected to begin around end of April. We'll do our best to resolve these by then, but some of them may require a bit more time.

[tylersmalley]

@joshdover, many thanks. The end of April would probably be the most optimistic timeline assuming everything goes smoothly and there aren't any developer experience issues we discover with the migration we will need to work on resolving.

[pgayvallet]

@mistic Can this one be closed?