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
Conversation
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.
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 |
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.
Is there a way to do this without the need for the let
and the eslint
comment? (I'm no TypeScript expert...)
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 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.
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 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 :(
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.
Suggestion for the enum definitions and locking down the TS version. Other than that LGTM.
@@ -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 |
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 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
02a828f
to
4b22524
Compare
@mathiasbynens I've rewritten the commit message 👍 |
Alright, let's do it! Thanks everyone :) |
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 castwindow 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.