cli(tsc): make LH.Flags type correct and consistent #5849
Conversation
brendankenny
changed the title
| * @param {Partial<LH.Flags>=} flags | ||
| * @return {Partial<LH.Config.Settings>} | ||
| */ | ||
| * @return {RecursivePartial<LH.Config.Settings>} |
There was a problem hiding this comment.
It's a bug that this wasn't flagged before, but it wasn't until I made any change to LH.Flags.output that it started to be flagged (even though the problem is with LH.Flags.throttling, weirdly enough).
We just want to copy any Settings properties over from an instance of Flags, so the result will only have Settings properties but some may not be set. So Partial<LH.Config.Settings> would be correct if Settings were a simple object.
The issue is that one of the properties (throttling) is itself an object, and while Flags.throttling has all optional properties, on Settings.throttling they're all required. This change applies Partial<> to all of Settings properties recursively. It could special case throttling instead, but this will catch any future objects added to SharedFlagsSettings as well.
typings/externs.d.ts
Outdated
| _: string[]; | ||
| chromeFlags: string; | ||
| outputPath: string; | ||
| saveAssets: boolean; | ||
| view: boolean; | ||
| enableErrorReporting: boolean; | ||
| enableErrorReporting?: boolean; |
There was a problem hiding this comment.
make this a yargs boolean instead. seems weird to have this one optional but the rest not.
There was a problem hiding this comment.
wait noooooo, we gotta revert this. it's purposefully not a yargs boolean so that the setting saved to their config will be respected. explicitly setting as false via yargs will always turn error reporting off
There was a problem hiding this comment.
whoops, very good point. There was a reason it wasn't in yargs.boolean() already :) I'll revert and add a comment so we don't do that again
I've had a few TODOs sprinkled in the code to
fix Flags type. I'm not exactly sure what I meant by that, but this PR makes sure our uses ofFlagsare all correct and gets to remove two places (index.jsandpopup.js) where we were coercing empty objects into Flags.We allowed empty objects as flags there, and now the type system actually verifies that that's completely acceptable :)
We already had
LH.FlagsvsLH.SharedFlagsSettings(all properties shared byLH.FlagsandLH.Config.Settings), and now I've added another level withLH.FlagsvsLH.CliFlags(all properties in addition toLH.Flagsthat control just CLI functionality). This is another step in makingFlagsa little easier to reason about, because once they reach core, all those CLI flags aren't visible anymore (according to the type system). This means code really doesn't have to care ifFlagsoriginated from the CLI, someone calling the node module, the extension, or devtools.Also spruces up type annotations in the CLI files (mostly removing
!s), which haven't been touched in a while.