-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate App services plugins to TS projects #87294
Conversation
@@ -5,7 +5,8 @@ | |||
*/ | |||
|
|||
import { buildOSSFeatures } from './oss_features'; | |||
import { featurePrivilegeIterator } from '../../security/server/authorization'; | |||
// @ts-expect-error | |||
import { featurePrivilegeIterator } from './feature_privilege_iterator'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
workaround to remove the circular dependency between features and security. @legrego wouldn't it be more appropriate to move this privilege assertion into the security
plugin test? https://github.com/elastic/kibana/pull/87294/files#diff-bb6d1fa1f497224ebef5f42ca080dc5baadd274b96fd8ebc99652071fd5a4a77R64
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Strictly speaking, yes! There was a reason we did it this way originally, but I'm struggling to remember why. It may have involved not wanting to export buildOSSFeatures
from the features
plugin, but looking at it now, it's no different than exporting featurePrivilegeIterator
from the security plugin 🤷.
I can add a task to address this in followup
Pinging @elastic/kibana-core (Team:Core) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Operations related changes LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes LGTM, but would be also good to get a second pair of 👀 on this from somebody who is more familiar with data
plugin.
@elasticmachine merge upstream |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. A few questions
return get(JSON.parse(content), 'compilerOptions.composite', false); | ||
return get(JSON5.parse(content), 'compilerOptions.composite', false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was there an issue with the default JSON parser?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tsconfig.json
is not strict JSON https://www.reddit.com/r/typescript/comments/8na5vb/tsconfigjson_isnt_strict_json_what_now/
src/plugins/data/common/index_patterns/index_patterns/fixtures/logstash_fields.js
Show resolved
Hide resolved
{ "path": "../../core/tsconfig.json" }, | ||
{ "path": "../expressions/tsconfig.json" }, | ||
{ "path": "../kibana_utils/tsconfig.json" }, | ||
{ "path": "../kibana_react/tsconfig.json" }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see you changed the expressions
import to be import type
, but I wonder if we should add expressions
as a requiredBundle
in ui_action
's kibana.json
file? I'm afraid of these inconsistencies between tsconfig.json
and kibana.json
, wdyt? Theorically, a plugin shouldn't import code (or even just types) from a plugin it doesn't have dependency on, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not an obligatory requirement since requiredBundle
is for runtime deps. I might add it to requiredBundle
, but there is no way to enforce it. One way to do so is to generate tsconfig.json
file from kibana.json
when all the plugins migrate to TS projects. @spalger WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We verify that people don't have unnecessary requiredBundles
by ensuring that each is actually used, but we aren't able to do that if we start including type-only dependencies in the list. I think it's better to keep the requiredBundles
array as small as possible and that includes removing type-only dependencies as well as bundles which are no longer required because usage was removed.
"include": [ | ||
"common/**/*", | ||
"public/**/*", | ||
"public/autocomplete/providers/kql_query_suggestion/__fixtures__/*.json", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is "public/autocomplete/providers/kql_query_suggestion/__fixtures__/*.json"
explicitly needed for json files? I don't see any similar inclusion in
Line 3 in 1ec2f1d
"include": ["mocks.ts", "typings/**/*", "plugins/**/*", "tasks/**/*"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems to be a bug in tsc
when building composite project with resolveJsonModule: true
microsoft/TypeScript#25636
I will add a comment to the tsconfig.json
file.
// name esType | | |metadata | subType | ||
['bytes', 'long', true, true, { count: 10 }], | ||
['ssl', 'boolean', true, true, { count: 20 }], | ||
['@timestamp', 'date', true, true, { count: 30 }], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This fixture still exists in src/fixtures
and is being used in other plugins, any reason why we started duplicating them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, fixtures
folder doesn't have an owner. This file is used by data
and discover
plugins only. If you want to keep them in sync, we might need to consider exporting them from the data
plugin.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So what would be the rule of thumb of what goes into src/fixtures
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what goes into src/fixtures?
nothing. it should be removed eventually. global folders won't exist when we move to domain-based folder structure #71566
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
data plugin changes LGTM
- copy of fixtures into the plugin
- adding the tsconfig.json file
@elasticmachine merge upstream |
💚 Build SucceededMetrics [docs]Distributable file count
History
To update your PR or re-run it, just comment with: |
* migrate expressions to ts project refs * bfetch to ts project * ui_actions to ts project * move fitures to data plugins * add data ts project * remove outdated ts-expect-error * add data to x-pack tsconfigs * navigation to ts project * cleanup licensing tsconfig * saved_objects to ts project * embeddable to ts project * ui_actions_enhanced to ts project * embeddable_enhanced to ts project * features to ts project * data_enhanced to ts project refs * fix i18n check * fix find_plugins_ready_to_migrate_to_ts_refs script * add a comment for bug ignoring json for composite projects Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Summary
part of #80508
Migrated @elastic/kibana-app-services plugins to the TS projects.
Migrated
save_objects
andfeatures
plugins as several plugins depend on them.Moved code from
examples
andfixtures
to appropriate plugins to remove unnecessary dependencies.Fixed script searching for plugins ready to be migrated to TS projects.
Impact
tsc --extendedDiagnostics
before:
OSS:
x-pack:
after
OSS
x-pack