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

Upgrade to TypeScript 3.5 #5556

Merged
merged 1 commit into from Mar 31, 2020
Merged

Upgrade to TypeScript 3.5 #5556

merged 1 commit into from Mar 31, 2020

Conversation

jackfranklin
Copy link
Collaborator

TS 3.5 got much stricter on writing changes to objects with varied types
1 so we have to do a bit of typecasting work to convince TS about the
types of keys and values that we are setting.

Longer term we should think about a better data structure that avoids us
having to jump through some hoops but for now I think this is a
reasonable step to get us onto 3.5.

Same story regarding bindings on window, the easiest fix is to cast
window to any for the code that adds to it. I'm sure we can come up with
a more type-safe way of doing this in the future.

Copy link
Member

@mathiasbynens mathiasbynens left a comment

Choose a reason for hiding this comment

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

Nit: please change the commit message to follow https://github.com/puppeteer/puppeteer/blob/master/CONTRIBUTING.md#commit-messages

@TimvdLippe Do you wanna take a look?

@@ -329,7 +329,9 @@ class AXNode {
role: this._role
};

/** @type {!Array<keyof SerializedAXNode>} */
/** @enum {'name'|'value'|'description'|'keyshortcuts'|'roledescription'|'valuetext'} */
let UserStringProperties; // eslint-disable-line no-unused-vars
Copy link
Member

Choose a reason for hiding this comment

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

Is there a way to do this without the need for the let and the eslint comment? (I'm no TypeScript expert...)

Copy link
Contributor

Choose a reason for hiding this comment

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

I am not sure if this actually works, but it is worth a try:

/** @enum {string} */
const UserStringProperties = {
  Name: 'name',
  Value: 'value',
  ...
}

Then you can do Object.values(UserStringProperties) instead of the userStringProperties array down below.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I tried this but it unfortunately doesn't work, because when you do for foo in Object.values(UserStringProperties) TypeScript only knows that foo is a string; it loses the fact that it was actually one of UserStringProperties, which causes problems. So I think this is the nicest way for now :(

Copy link
Contributor

@TimvdLippe TimvdLippe left a comment

Choose a reason for hiding this comment

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

Suggestion for the enum definitions and locking down the TS version. Other than that LGTM.

package.json Outdated Show resolved Hide resolved
@@ -329,7 +329,9 @@ class AXNode {
role: this._role
};

/** @type {!Array<keyof SerializedAXNode>} */
/** @enum {'name'|'value'|'description'|'keyshortcuts'|'roledescription'|'valuetext'} */
let UserStringProperties; // eslint-disable-line no-unused-vars
Copy link
Contributor

Choose a reason for hiding this comment

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

I am not sure if this actually works, but it is worth a try:

/** @enum {string} */
const UserStringProperties = {
  Name: 'name',
  Value: 'value',
  ...
}

Then you can do Object.values(UserStringProperties) instead of the userStringProperties array down below.

TS 3.5 got much stricter on writing changes to objects with varied types
[1] so we have to do a bit of typecasting work to convince TS about the
types of keys and values that we are setting.

Longer term we should think about a better data structure that avoids us
having to jump through some hoops but for now I think this is a
reasonable step to get us onto 3.5.

Same story regarding bindings on `window`, the easiest fix is to cast
window to any for the code that adds to it. I'm sure we can come up with
a more type-safe way of doing this in the future.

[1]: https://github.com/Microsoft/TypeScript/wiki/Breaking-Changes#fixes-to-unsound-writes-to-indexed-access-types
@jackfranklin
Copy link
Collaborator Author

@mathiasbynens I've rewritten the commit message 👍

@mathiasbynens
Copy link
Member

Alright, let's do it! Thanks everyone :)

@mathiasbynens mathiasbynens merged commit 5e8d79b into master Mar 31, 2020
@mathiasbynens mathiasbynens deleted the upgrade-typescript-3.5 branch March 31, 2020 08:48
@mathiasbynens mathiasbynens added this to the TypeScript migration milestone Apr 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants