[Meta] Migrate plugins to TS references for es_ui CODEOWNERS plugins

[TinaHeiligers]

Summary

Now that the Kibana build system supports using TypeScript project references (#46773), the es_ui team need help migrating their plugins. This is part of the overall effort tracked at #80508.

plugin	migration status
cross_cluster_replication	✅
index_lifecycle_management	✅
grokdebugger	✅
index_management	✅
license_management	✅
painless_lab	✅
remote_clusters	✅
rollup	✅
snapshot_restore	✅
upgrade_assistant	✅
watcher	✅
ingest_pipelines	✅

Migration order:

1. plugins ready to migrate (no blockers):
   - watcher Migrates watcher to a TS project ref #89622
   - snapshot_restore TS project refs: Migrates snapshot_restore to a TS Project #89653
   - painless_lab Converts painlessLab to a TS project reference #89626
   - license_management Migrates license_management to a TS project ref #89472
   - grokdebugger TS project refs: Migrates grokdebugger #89652
   - ingest_pipelines Migrates ingest_pipelines to a TS project ref #89505
   - index_management Migrates index_management & runtime_fields to TS project refs #89809 (Circular dependency removed)
   - upgrade_assistant -> (Ts project refs: Migrates Upgrade Assistant to a TS project #89949)
2. plugins blocked by circular dependencies
   - index_management Migrates index_management & runtime_fields to TS project refs #89809
   • index_lifecycle_management (depends on index_management)
   • remote_clusters (depends on index_management)
   • rollup (depends on index_pattern_management Migrate indexPatternManagement to TS project ref #89759 & index_management)
   • cross_cluster_replication (depends on remote_clusters & index_management)

Blockers (if any)

Blockers: ⚠️ Circular dependency between infra <--> apm <--> infra for
cross_cluster_replication, index_lifecycle_management, index_management, remote_clusters, rollup

Acceptance criteria

The telemetry-related plugins can be referred to using a project reference, which means each...

• has a tsconfig.json file which conforms to the documented form
• references the dependencies
• emits type definitions for its public API
• compiles in tsc's build mode

Related information

• https://github.com/elastic/kibana/blob/master/docs/developer/best-practices/typescript.asciidoc#project-references
• https://www.typescriptlang.org/docs/handbook/project-references.html

[TinaHeiligers]

Blocked plugins and dependencies

index_management (5) (DONE)

Dependencies

- [ ] apm (#81003)

• indexPatternManagement (Migrate indexPatternManagement to TS project ref #89759)
  - [x] infra
• licenseManagement
• maps
• mapsLegacy
• mapsOss
  - [ ] ml
  - [ ] observability

index_lifecycle_management (12)

Dependencies

- [ ] apm (#81003)

• fleet ([Fleet] Use TS project references #87574)
• indexManagement (Migrates index_management & runtime_fields to TS project refs #89809)
• indexPatternManagement (Migrate indexPatternManagement to TS project ref #89759)
• infra ([Logs + Metrics UI] Migrate to TS project references #80995)
• licenseManagement
• mapsLegacy
• mapsOss
• maps
• ml ([ML] Migrate ML plugin to TS project references #89270)
• observability (TypeScript project references for Observability plugin #89320)
• runtimeFields (Migrates index_management & runtime_fields to TS project refs #89809)

remote_clusters (12)

Dependencies

- [ ] apm (#81003)

• fleet ([Fleet] Use TS project references #87574)
• indexManagement (Migrates index_management & runtime_fields to TS project refs #89809)
• indexPatternManagement (Migrate indexPatternManagement to TS project ref #89759)
• infra ([Logs + Metrics UI] Migrate to TS project references #80995)
• licenseManagement
• maps
• mapsLegacy
• mapsOss
• ml ([ML] Migrate ML plugin to TS project references #89270)
• observability (TypeScript project references for Observability plugin #89320)
• runtimeFields (Migrates index_management & runtime_fields to TS project refs #89809)

rollup (12)

Dependencies

- [ ] apm (#81003)

• fleet ([Fleet] Use TS project references #87574)
• indexManagement (Migrates index_management & runtime_fields to TS project refs #89809)
• indexPatternManagement (Migrate indexPatternManagement to TS project ref #89759)
• infra ([Logs + Metrics UI] Migrate to TS project references #80995)
• licenseManagement
• maps
• mapsLegacy
• mapsOss
• ml ([ML] Migrate ML plugin to TS project references #89270)
• observability (TypeScript project references for Observability plugin #89320)
• runtimeFields (Migrates index_management & runtime_fields to TS project refs #89809)

cross_cluster_replication (13)

Dependencies

- [ ] apm (#81003)

• fleet ([Fleet] Use TS project references #87574)
• indexManagement (Migrates index_management & runtime_fields to TS project refs #89809)
• indexPatternManagement (Migrate indexPatternManagement to TS project ref #89759)
• infra ([Logs + Metrics UI] Migrate to TS project references #80995)
• licenseManagement
• maps
• mapsLegacy
• mapsOss
• ml ([ML] Migrate ML plugin to TS project references #89270)
• observability (TypeScript project references for Observability plugin #89320)
• remoteClusters
• runtimeFields (Migrates index_management & runtime_fields to TS project refs #89809)

[TinaHeiligers]

@restrry the watcher plugin has a plain json file that's being imported in a few places. For example:

// x-pack/plugins/watcher/tests_client_integration
import defaultWatchJson from '../public/application/models/watch/default_watch.json';

With the following tsconfig.json:

//x-pack/plugins/watcher/tsconfig.json
{
  "extends": "../../../tsconfig.base.json",
  "compilerOptions": {
    "composite": true,
    "outDir": "./target/types",
    "emitDeclarationOnly": true,
    "declaration": true,
    "declarationMap": true
  },
  "include": [
    "common/**/*",
    "public/**/**/**/*",
    "server/**/*",
    "tests_client_integration/**/*",
    "__fixtures__/**/*",
    "../../typings/**/*"
  ],
  "references": [
    { "path": "../../../src/core/tsconfig.json" },
    { "path": "../licensing/tsconfig.json" },
    { "path": "../features/tsconfig.json" },
    { "path": "../../../src/plugins/home/tsconfig.json"},
    { "path": "../../../src/plugins/charts/tsconfig.json"},
    { "path": "../../../src/plugins/data/tsconfig.json"},
    { "path": "../../../src/plugins/management/tsconfig.json"},
    { "path": "../../../src/plugins/es_ui_shared/tsconfig.json"},
    { "path": "../../../src/plugins/kibana_react/tsconfig.json"},
  ]
}

I get the following error that I can't seem to get around:

➜  kibana git:(watcher-to-ts-ref) ✗ ./node_modules/.bin/tsc -b x-pack/plugins/watcher
x-pack/plugins/watcher/tests_client_integration/watch_create_json.test.ts:11:30 - error TS6307: File '/Users/christianeheiligers/Projects/kibana/x-pack/plugins/watcher/public/application/models/watch/default_watch.json' is not listed within the file list of project '/Users/christianeheiligers/Projects/kibana/x-pack/plugins/watcher/tsconfig.json'. Projects must list all files or use an 'include' pattern.

11 import defaultWatchJson from '../public/application/models/watch/default_watch.json';
                                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Found 1 error.

Please forgive me if you've answered this before but how would one get around this?
I'm trying to resolve the issue by creating a new file and converting the json object to a js const. There are a few failing tests now though and I'm not sure how much we should be fiddling with the es_ui team's code or if I can fix them.

[TinaHeiligers]

@cjcenizal perhaps you can help me out with the watcher migration issue above? The TL;DR is that defaultWatchJson is declared in a .json file and typescript complains. When I change the defaultWatchJson to a js object, there are a few failing unit tests and the behavior is not the same. I'm not familiar with the watcher code and don't want to 'mess' with it too much. Thanks!

[cjcenizal]

@TinaHeiligers Thanks for helping us with this and for the ping! I'll take a look at Watcher. In the meantime, do you want to move it to the bottom of your list so you get to it last? I might also suggest prioritizing license management, since according to the meta issue it's blocking ML.

[TinaHeiligers]

@cjcenizal thank you for taking a look at watcher!

I'll prioritize license_management and will ping in this issue if there are similar problems.

In the mean time, we need to remove the dependency between feet and index_management.
index_management is a low level plugin used by many other plugins and ATM, it depends on fleet. The only reason that there is a dependency on fleet is to generate a link to the fleet app.

Could someone from the @elastic/es-ui team either look into removing that dependency as a priority?
Thanks!

[cjcenizal]

@TinaHeiligers

we need to remove the dependency between fleet and index_management.

Can you help me understand this need?

The only reason that there is a dependency on fleet is to generate a link to the fleet app

Are you aware of an alternative way to do this? If fleet isn't enabled, we don't want to render a link to it. What's the correct way to assert against whether it's enabled or not without declaring it an optional dependency?

[TinaHeiligers]

@cjcenizal, @restrry asked me to reach out about removing the dependency on fleet.
Migrating index_management to a TS project is blocked by a circular dependency between infra and apm.
The dependency chain is: index_management --> fleet --> infra --> apm
If we can remove the dependency on fleet, we (hopefully) won't need to wait for the circular dependency to be resolved (from my understanding of the request but I might be wrong here)

As for alternative ways of checking if fleet is enabled, is there a config setting you can check?

[cjcenizal]

@TinaHeiligers Thanks for explaining. I asked around and it sounds like we're following best practices in index_management. You mentioned the circular dependency lies between infra and apm. I think we should focus on solving that problem directly rather than trying to work around the downstream effects.

[TinaHeiligers]

Blockers for migrating upgrade_assistant:
1. Find an alternative for reading the current version merged

// x-pack/plugins/upgrade_assistant/common/version.ts
import pkg from '../../../../package.json' // we're importing kibana/package.json

2. Find a way to reference xpackMocks: Resolved with duplicating the mock used in one particular test.

3. Convert AssistanceData from .json to .ts:

4. Convert fakeDeprecations from .json to .ts:

TIL: one needs to explicitly declare .json in the tsconfig.json as follows:

// tsconfig.json
...
  },
  "include": [
    "common/**/*",
    // have to declare *.json explicitly due to https://github.com/microsoft/TypeScript/issues/25636
    "public/**/*.json",
    "server/**/*"
  ],
...

cc @elastic/es-ui

@elastic/kibana-core Does anyone have advice on how to handle 1 & 2? I can get around 3 & 4.

[cjcenizal]

@alisonelizabeth Could you help Tina out with 1 and 2 above?

[alisonelizabeth]

I can look into this on Friday.

[mshustov]

@TinaHeiligers what's the problem with json files? The same as here?

kibana/x-pack/plugins/actions/tsconfig.json

Lines 12 to 13 in 8b1a228

	// have to declare *.json explicitly due to https://github.com/microsoft/TypeScript/issues/25636
	"server/**/*.json",

[TinaHeiligers]

@restrry oh wow, I didn't know we could do that!
Thanks

[alisonelizabeth]

@TinaHeiligers Just a quick update on UA - I can read the current version from PluginInitializerContext.env.packageInfo.version instead of package.json. I will also handle xpackMocks. I'll tag you when I have a PR up.