Skip to content
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

Merged
merged 7 commits into from
Feb 28, 2019

Conversation

mshustov
Copy link
Contributor

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

For maintainers

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@mshustov mshustov changed the title Update Typescript to latest version Update Typescript to the latest version Feb 26, 2019
@mshustov mshustov marked this pull request as ready for review February 26, 2019 18:38
@mshustov mshustov requested review from a team as code owners February 26, 2019 18:38
@mshustov mshustov added Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Team:Operations Team label for Operations Team labels Feb 26, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-platform

@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-operations

@mshustov mshustov added the non-issue Indicates to automation that a pull request should not appear in the release notes label Feb 26, 2019
Copy link
Contributor

@spalger spalger left a 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 } {
Copy link
Contributor

@spalger spalger Feb 26, 2019

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:

image

Copy link
Contributor

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.

Copy link
Contributor

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.

@mshustov mshustov added the chore label Feb 27, 2019
Copy link
Contributor

@timroes timroes left a 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.

@timroes timroes dismissed their stale review February 27, 2019 09:17

Found a solution for the vis_update problem, lifting my review assuming this will be fixed.

@@ -255,6 +255,7 @@ export const RangeDatePicker = injectI18n(
id="QuickSelectPopover"
button={quickSelectButton}
isOpen={this.state.isPopoverOpen}
// @ts-ignore
Copy link
Contributor Author

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
Copy link
Contributor Author

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'.

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@mshustov mshustov requested review from sorenlouv and timroes and removed request for sorenlouv February 27, 2019 13:20
Copy link
Member

@sorenlouv sorenlouv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 from APM

@mshustov mshustov mentioned this pull request Feb 27, 2019
8 tasks
defaultMessage: 'Find a space',
})}
incremental={true}
// FIXME needs updated typedef
Copy link
Contributor

@kobelb kobelb Feb 27, 2019

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?

Copy link
Contributor Author

@mshustov mshustov Feb 28, 2019

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

Copy link
Contributor

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.

@mshustov mshustov merged commit 8c6b1e5 into elastic:master Feb 28, 2019
@mshustov mshustov deleted the issue-31486-update-ts branch February 28, 2019 16:21
mshustov added a commit to mshustov/kibana that referenced this pull request Feb 28, 2019
* 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
mshustov added a commit to mshustov/kibana that referenced this pull request Feb 28, 2019
didn't merge latest master in elastic#32063
mshustov added a commit to mshustov/kibana that referenced this pull request Feb 28, 2019
* 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
mshustov added a commit that referenced this pull request Feb 28, 2019
didn't merge latest master in #32063
mshustov added a commit that referenced this pull request Feb 28, 2019
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backported chore non-issue Indicates to automation that a pull request should not appear in the release notes Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Team:Operations Team label for Operations Team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants