deps: update to [email protected] #12909
Conversation
| */ | ||
| const mergeOptionsOfItems = function(items) { | ||
| /** @type {Array<{id: string, path?: string, options?: Object<string, any>}>} */ | ||
| /** @type {T[]} */ |
There was a problem hiding this comment.
Previously this was implicitly downcasting mergedItems back to T[] on return. Something in 4.3 no longer allows this, so it needs to be T[] from the start
| @@ -205,7 +205,7 @@ function gatherTapTargets(tapTargetsSelector, className) { | |||
|
|
|||
| /** @type {{ | |||
| tapTargetElement: Element, | |||
| clientRects: ClientRect[] | |||
| clientRects: LH.Artifacts.Rect[] | |||
There was a problem hiding this comment.
these haven't been real ClientRects in a long time. Not sure why this wasn't previously an error.
| @@ -90,10 +90,16 @@ function computeDescription(ast, message) { | |||
|
|
|||
| /** | |||
| * Collapses a jsdoc comment into a single line and trims whitespace. | |||
| * @param {string=} comment | |||
| * @param {import('typescript').JSDoc['comment']} comment | |||
There was a problem hiding this comment.
tsc 4.3 added support for @link tags in 4.3, so jsdoc comments aren't always just simple strings anymore, sometimes they're structured data. Our UIStrings jsdoc comments are still just strings for now, though, so everything still works the same.
There is some movement in their code to take a more array-of-text-nodes generalized approach to jsdoc comments, so I left a comment in here in case it ever does start failing.
| @@ -197,11 +197,13 @@ export class LighthouseReportViewer { | |||
| _replaceReportHtml(json) { | |||
| // Allow users to view the runnerResult | |||
| if ('lhr' in json) { | |||
| json = /** @type {LH.RunnerResult} */ (json).lhr; | |||
| const runnerResult = /** @type {LH.RunnerResult} */ (/** @type {unknown} */ (json)); | |||
There was a problem hiding this comment.
Perfectly reasonable complaint that the existing casts are garbage. This maintains the garbage but makes it clear we know what it is :)
| @@ -442,7 +442,7 @@ export class ReportUIFeatures { | |||
| }); | |||
| } | |||
| } | |||
| } catch (/** @type {Error} */ e) { | |||
| } catch (e) { | |||
There was a problem hiding this comment.
only unknown is allowed for catch clause variables now
| @@ -6,6 +6,8 @@ | |||
| "allowJs": true, | |||
| "checkJs": true, | |||
| "strict": true, | |||
| // TODO: turn this off to be fully `strict`. | |||
| "useUnknownInCatchVariables": false, | |||
There was a problem hiding this comment.
this would make all catch clause variables unknown (instead of the current default any), so we would always have to do typeof/instanceof/x in err checks before taking properties off of errors.
That's the right way to do it in JS, where code can throw whatever it wants, but we probably aren't ready to commit to that yet
I was doing an update to 4.3.5 when the 4.4 release candidate came out. The 4.4 perf improvements really help with the continuing split up of tsconfigs, so it would be nice to land now.
The fixes needed in existing code are kind of random but are each a reasonable change.