-
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
Update Typescript to the latest version #32063
Conversation
💚 Build Succeeded |
Pinging @elastic/kibana-platform |
Pinging @elastic/kibana-operations |
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.
One thing, but LGTM otherwise
@@ -59,8 +59,8 @@ function getUpdateStatus<T extends Status>( | |||
requiresUpdateStatus: T[] = [], | |||
obj: any, | |||
param: { vis: Vis; visData: any; uiState: PersistedState } | |||
): { [reqStats in T]: boolean } { | |||
const status = {} as { [reqStats in T]: boolean }; | |||
): { [reqStats in Status]: boolean } { |
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.
Took a double look at this, I think we'd be better off getting rid of the T extends Status
bit and just using Status
in place of T
everywhere.
function getUpdateStatus(
requiresUpdateStatus: Status[] = [],
obj: any,
param: { vis: Vis; visData: any; uiState: PersistedState }
): { [reqStats in Status]: boolean } {
const status = {} as { [reqStats in Status]: boolean };
...
@timroes do you remember why this uses T extends Status
instead of just referencing the Status enum directly? The indirection seems to have worked in the past but is now confusing TypeScript which complains about the assignments to status.aggs
and such below:
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.
Because we know that the return object doesn't have all possible values of the Status
enum as a key, so reqStats in Status
is simply wrong. The method signature was in a way so that you pass in an array of enum values as a parameter and the result object will have exactly only those enum values as keys (not more not less from the enum) and boolean value for each of them.
Earlier the correct syntax for that was like that. [reqStats in Status]
is definitely the wrong typing, since it would say the result object has ALWAYS all the enum values as keys, which it doesn't. I can try to look into that today or tomorrow to find a better solution, that will still break. The least thing that should still work is { [reqStats in Status]?: boolean }
which allows each of the keys to be undefined. Since we're losing type information like that, that we're currently having I would like to check if there is another better way to solve that.
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 tested it. You can simply revert that line again. It's enough if you instantiate the status
object in the next line as { [reqStats in Status]: boolean }
(as you already do). That line can stay the same. And TypeScript won't complain anymore, but will still have the nice syntax for the caller, that the return object will only contain the requested keys.
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 vis_update typing is currently broken. Will try to help out as soon as I can to find a better solution.
Found a solution for the vis_update problem, lifting my review assuming this will be fixed.
x-pack/plugins/apm/public/components/app/ServiceDetails/ServiceIntegrations/WatcherFlyout.tsx
Outdated
Show resolved
Hide resolved
@@ -255,6 +255,7 @@ export const RangeDatePicker = injectI18n( | |||
id="QuickSelectPopover" | |||
button={quickSelectButton} | |||
isOpen={this.state.isPopoverOpen} | |||
// @ts-ignore |
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.
here callback is defined as private closePopover = (type: string, from?: string, to?: string) => {
but closePopover
in <EuiPopover
doesn't pass any arguments. tried to fix it with making all params optional
private closePopover = (type?: string, from?: string, to?: string) => {
but it leads to other errors in this file, so suppressed for now
@@ -50,6 +50,7 @@ export const withStateFromLocation = <StateInLocation extends {}>({ | |||
const stateFromLocation = mapLocationToState(location); | |||
|
|||
return ( | |||
// @ts-ignore |
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.
Probably author could help with this error
Type 'Readonly<{ children?: ReactNode; }> & Readonly<RouteComponentProps<{}, StaticContext, any> & Pick<WrappedComponentProps, Exclude<keyof WrappedComponentProps, keyof StateInLocation | "pushStateInLocation" | "replaceStateInLocation">>> & StateInLocation & { ...; }' is not assignable to type 'IntrinsicAttributes & WrappedComponentProps & { children?: ReactNode; }'.
Type 'Readonly<{ children?: ReactNode; }> & Readonly<RouteComponentProps<{}, StaticContext, any> & Pick<WrappedComponentProps, Exclude<keyof WrappedComponentProps, keyof StateInLocation | "pushStateInLocation" | "replaceStateInLocation">>> & StateInLocation & { ...; }' is not assignable to type 'WrappedComponentProps'.
💚 Build Succeeded |
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.
👍 from APM
defaultMessage: 'Find a space', | ||
})} | ||
incremental={true} | ||
// FIXME needs updated typedef |
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 used to be able to put the // @ts-ignore
directly above the invalid prop, which meant if we had another invalid prop we'd get a TSC error. Moving this to on top of the EuiFieldSearch
allows the entire element to be invalid. Do you know why we can't do the previous approach any longer?
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.
@kobelb
unfortunately not. They has changed reporting mechanism for missing property error microsoft/TypeScript#26423
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'm not finding any alternatives at this point in time, but it does eliminate the targeting ignoring that we used to be able to perform, which means we really shouldn't be relying on ts-ignore in these situations. I'll open a PR to fix the type defs in EUI and get rid of these in a subsequent PR.
* bump typescript version to 3.3.3333 * fix tests after updating TS version * suppress type errors until they fixed appropriately * address comments * add type def for UnconnectedKibanaLink * remove fix @ts-ignore * fix snapshot test. provide displayName
didn't merge latest master in elastic#32063
* bump typescript version to 3.3.3333 * fix tests after updating TS version * suppress type errors until they fixed appropriately * address comments * add type def for UnconnectedKibanaLink * remove fix @ts-ignore * fix snapshot test. provide displayName
didn't merge latest master in #32063
* Update Typescript to the latest version (#32063) * bump typescript version to 3.3.3333 * fix tests after updating TS version * suppress type errors until they fixed appropriately * address comments * add type def for UnconnectedKibanaLink * remove fix @ts-ignore * fix snapshot test. provide displayName * update lost test
Summary
Working on issue #31486, after finishing #31825 I realised that
node scripts/type_check
indicates some type errors, while VSCode with the latest TS does not detect any problems.Checklist
[ ] This was checked for cross-browser compatibility, including a check against IE11[ ] Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support[ ] Documentation was added for features that require explanation or tutorials[ ] This was checked for keyboard-only and screenreader accessibilityFor maintainers