cli: update documented throttling flags #5000
Conversation
patrickhulce
requested review from
paulirish and
vinamratasingal-zz
as code owners
patrickhulce
changed the title
There was a problem hiding this comment.
LGTM
we should probably explore an automated way of keeping those flags in sync with our SettingsJson typedefs
some ideas:
- on the typescript side, instead of using
@types/yargswith its generic interface, we could lie to the compiler and tell it this only returns our settings object based on the inputs, then we could do some checking... (e.g.describefirst arguments all come from the settings,boolean()values do too and all have to be boolean, etc) - we could do a
sample_v2.json-like check with for cli--helpoutput vs the usage section in the readme . Don't know how messy it'll get with whitespace and whatnot. - runtime check of properties coming in as flags vs
defaultSettings. No excess properties, expected types, etc. Since the defaults has the right shape checked at compile time, it can in turn ensure the right shape at run time.
docs/throttling.md
Outdated
| @@ -50,7 +50,7 @@ Currently, `comcast` will also throttle the websocket port that Lighthouse uses | |||
| comcast --latency=150 --target-bw=1600 | |||
|
|
|||
| # Run Lighthouse with it's own throttling disabled | |||
There was a problem hiding this comment.
will you fix the it's while youre in here?
| @@ -76,7 +76,7 @@ instance with an open debugging port. | |||
|
|
|||
| Lighthouse can run against a real mobile device. You can follow the [Remote Debugging on Android (Legacy Workflow)](https://developer.chrome.com/devtools/docs/remote-debugging-legacy) up through step 3.3, but the TL;DR is install & run adb, enable USB debugging, then port forward 9222 from the device to the machine with Lighthouse. | |||
|
|
|||
| You'll likely want to use the CLI flags `--disable-device-emulation --disable-cpu-throttling` and potentially `--disable-network-throttling`. | |||
| You'll likely want to use the CLI flags `--disable-device-emulation --throttling.cpuSlowdownMultiplier`. | |||
| @@ -33,8 +33,8 @@ function getFlags(manualArgv) { | |||
| 'lighthouse <url> --output=json --output-path=./report.json --save-assets', | |||
| 'Save trace, screenshots, and named JSON report.') | |||
| .example( | |||
| 'lighthouse <url> --disable-device-emulation --disable-network-throttling', | |||
| 'Disable device emulation') | |||
| 'lighthouse <url> --disable-device-emulation --throttling-method=provided', | |||
There was a problem hiding this comment.
thoughts for another day: --throttling-method=provided -- this is kind of unfortunate wording if you really do just want throttling off. We could maybe make none or something that's basically like provided, though we probably don't want to make it a strict alias...
There was a problem hiding this comment.
yeah I also think this is awkward. Now with our laternification do we need our user to inform us if the throttling is off or provided? If not, then I think we should rename provided (and maybe even throttling-method).
Either way it's possible we have to introduce some CLI sugar that may be inconsistent with the config..
There was a problem hiding this comment.
Yeah I agree it's odd, there's no difference between off and provided I'm fine to rename to whatever in followup 👍
doing some cleanup on the remaining references to the old
disable-X-throttlingflags, we should probably explore an automated way of keeping those flags in sync with ourSettingsJsontypedefs now that all the options are available to CLInot sure if it's really better to piecemeal update readme like this or do a pass over our docs and re-evaluate if we still want to tell people to be doing things like we are