proto: update processForProto method signature, string -> LH.Result #9016

paulirish · 2019-05-21T23:11:07Z

Also, lightrider will only request JSON output now.

brendankenny · 2019-05-21T23:27:17Z

does this supersede #9002?

brendankenny · 2019-05-21T23:31:33Z

does this supersede #9002?

oh, jk, only touching results.lhr

brendankenny

some nits, but LGTM otherwise

lighthouse-core/lib/proto-preprocessor.js

brendankenny · 2019-05-21T23:29:47Z

lighthouse-core/test/lib/proto-preprocessor-test.js

@@ -5,7 +5,7 @@
 */
 'use strict';

-const processForProto = require('../../lib/proto-preprocessor').processForProto;


can you add a test that it doesn't modify the passed-in lhr?

brendankenny · 2019-05-21T23:34:38Z

clients/lightrider/lightrider-entry.js

 * @param {{lrDevice?: 'desktop'|'mobile', categoryIDs?: Array<string>, logAssets: boolean, configOverride?: LH.Config.Json}} lrOpts Options coming from Lightrider
- * @return {Promise<string|Array<string>|void>}
+ * @return {Promise<string|void>}


is void still a return possibility? (I think it can be dropped now)

is void still a return possibility?

Oh, yes it is for the if (!results) return case. Should it throw to get a runtime error when that happens? Weird to return nothing if Lighthouse was acting poorly (I think it's actually a // should never happen case to make tsc happy).

brendankenny · 2019-05-21T23:35:14Z

clients/lightrider/lightrider-entry.js

@@ -25,9 +25,9 @@ const LR_PRESETS = {
 * If configOverride is provided, lrDevice and categoryIDs are ignored.
 * @param {Connection} connection
 * @param {string} url
- * @param {LH.Flags} flags Lighthouse flags, including `output`
+ * @param {LH.Flags} flags Lighthouse flags


make sure you aren't accidentally still passing in output: 'html' and doing all that extra work :)

Added a comment.. i dont think we need a stronger check.

Added a comment.. i dont think we need a stronger check.

yeah, I meant just double check existing code, definitely don't need a check in the code

connorjclark · 2019-05-21T23:45:57Z

lighthouse-core/lib/proto-preprocessor.js

-  /** @type {LH.Result} */
-  const reportJson = JSON.parse(result);
+function processForProto(lhr) {
+  const reportJson = JSON.parse(JSON.stringify(lhr));


could we skip the cloning? Only the lr entry uses this fn, and the original lhr is not needed there. if some other client comes along with different requirements they can clone the input themselves.

assuming cloning a lhr takes a measurable amount of time.

I clocked 4ms for example.com and for 8ms nyt.com:

console.time('clone'); JSON.parse(JSON.stringify(lhr)); console.timeEnd('clone');

I find it unexpected when methods mutate the passed in object, so this is my preferred pattern. It's also what we do for Util.prepareReportResult, swapLocale, our tests, etc.

We adopted this pattern in our tests, as previously we had some unexpected mutations that caused failures that were tricky to track down.

yeah I prefer avoiding mutation too. if the few ms is worth the change, I'd suggest renaming the method to modifyForProto to properly set expectations.

clients/lightrider/lightrider-entry.js

Co-Authored-By: Brendan Kenny <bckenny@gmail.com>

brendankenny

some comments on comments and need to fix the type error, but otherwise LGTM.

Love the simplification!

brendankenny · 2019-06-06T20:21:33Z

clients/lightrider/lightrider-entry.js

@@ -25,9 +25,9 @@ const LR_PRESETS = {
 * If configOverride is provided, lrDevice and categoryIDs are ignored.
 * @param {Connection} connection
 * @param {string} url
- * @param {LH.Flags} flags Lighthouse flags, including `output`
+ * @param {LH.Flags} flags Lighthouse flags


Added a comment.. i dont think we need a stronger check.

yeah, I meant just double check existing code, definitely don't need a check in the code

brendankenny · 2019-06-06T20:22:38Z

clients/lightrider/lightrider-entry.js

@@ -38,6 +38,7 @@ async function runLighthouseInLR(connection, url, flags, lrOpts) {
  flags.disableStorageReset = true;
  flags.logLevel = flags.logLevel || 'info';
  flags.channel = 'lr';
+  // flags.output assumed to be unset by Lightrider


yeah, probably just drop this line. At worst it's just extra work, and is just as assumed as every other property on flags could be (and we don't make a comment for any of those)

should it instead throw if output is set to anything other than undefined or json? seems like it could be frustrating to figure that out on your own

but you both seem to be on the same page that we "definitely don't need a check in the code" so I feel like I'm missing something

should it instead throw if output is set to anything other than undefined or json?

yeah, that's why I was suggesting removing the comment, because from this comment it definitely sounds like it should be an assertion, not a comment :)

AIUI, the runnerResult.report is ignored completely on the LR side now, it uses the LHR directly (with its own HTML reportGenerator bundle), so at worst a defined output is just extra work.

...but there are several possible things on flags that could add extra work and we're just assuming those are correct too, so I really don't think it's worth thinking about. Really it's something for the caller to worry about, either way anyways

brendankenny · 2019-06-06T20:26:38Z

clients/lightrider/lightrider-entry.js

-
-      return preprocessor.processForProto(runnerResult.report);
+    // When LR is called with |internal: {keep_raw_response: true, save_lighthouse_assets: true}|,
+    // this code will log artifacts to raw_response.artifacts.


this comment is inherited but is pretty confusing here since it appears to refer entirely to stuff outside of LH? e.g. keep_raw_response and/or save_lighthouse_assets somehow become lrOpts.logAssets, and lhr becomes raw_response?

If it's helpful for users of lr, though, seems ok to keep

brendankenny · 2019-06-06T20:30:54Z

clients/lightrider/lightrider-entry.js

+    // When LR is called with |internal: {keep_raw_response: true, save_lighthouse_assets: true}|,
+    // this code will log artifacts to raw_response.artifacts.
+    if (logAssets) {
+      // @ts-ignore - Regenerate the report, but tack on the artifacts.


maybe regenerate was referring to what it used to be doing? what about just // @ts-ignore - piggyback the artifacts on the LHR.

brendankenny · 2019-06-06T20:36:51Z

lighthouse-core/lib/proto-preprocessor.js

-  /** @type {LH.Result} */
-  const reportJson = JSON.parse(result);
+function processForProto(lhr) {
+  const reportJson = JSON.parse(JSON.stringify(lhr));


the type error (failure in travis) is because this whole function is operating on an any reportJson (due to the return type of JSON.parse). Luckily there was a forEach in there or we wouldn't have noticed the whole thing wasn't being checked :)

Need to keep the /** @type {LH.Result} */ above this line.

googlebot · 2019-06-07T00:11:36Z

A Googler has manually verified that the CLAs look good.

(Googler, please make sure the reason for overriding the CLA status is clearly documented in these comments.)

ℹ️ Googlers: Go here for more info.

patrickhulce

LGTM!

I guess the no more HTML in LR issue was prediscussed I missed? Because that seems like the much bigger visible change to me personally as an outsider 😆

patrickhulce · 2019-06-07T14:49:06Z

clients/lightrider/lightrider-entry.js

@@ -38,6 +38,7 @@ async function runLighthouseInLR(connection, url, flags, lrOpts) {
  flags.disableStorageReset = true;
  flags.logLevel = flags.logLevel || 'info';
  flags.channel = 'lr';
+  // flags.output assumed to be unset by Lightrider


should it instead throw if output is set to anything other than undefined or json? seems like it could be frustrating to figure that out on your own

but you both seem to be on the same page that we "definitely don't need a check in the code" so I feel like I'm missing something

googlebot · 2019-06-11T20:04:04Z

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

paulirish added 2 commits May 21, 2019 16:07

lightrider-entry can assume json now

c508f1f

processForProto took/returned a string, now takes/returns LH.Result.

455a20b

paulirish requested review from brendankenny and exterkamp May 21, 2019 23:11

paulirish requested a review from patrickhulce as a code owner May 21, 2019 23:11

brendankenny approved these changes May 21, 2019

View reviewed changes

connorjclark reviewed May 21, 2019

View reviewed changes

clients/lightrider/lightrider-entry.js Show resolved Hide resolved

This comment has been minimized.

Sign in to view

vercel bot deployed to staging May 21, 2019 23:56 View deployment

paulirish and others added 3 commits May 24, 2019 22:08

add test that input is not modified

204c0cf

Merge branch 'master' into jsoninlr

3bf14de

Update lighthouse-core/lib/proto-preprocessor.js

2ed7231

Co-Authored-By: Brendan Kenny <bckenny@gmail.com>

paulirish force-pushed the jsoninlr branch from 7215a4c to 2ed7231 Compare May 25, 2019 05:13

vercel bot deployed to staging May 25, 2019 05:13 View deployment

paulirish added 2 commits June 5, 2019 14:30

Merge branch 'master' into jsoninlr

3a49ae2

feedback and rebase updates

83debc0

vercel bot deployed to staging June 5, 2019 12:44 View deployment

googlebot added the cla: no label Jun 5, 2019

connorjclark approved these changes Jun 6, 2019

View reviewed changes

brendankenny approved these changes Jun 6, 2019

View reviewed changes

exterkamp added cla: yes and removed cla: no labels Jun 7, 2019

patrickhulce approved these changes Jun 7, 2019

View reviewed changes

final feedback

1fe5e33

paulirish added the land-when-ci-is-green label Jun 11, 2019

vercel bot deployed to staging June 11, 2019 20:04 View deployment

googlebot added cla: no and removed cla: yes labels Jun 11, 2019

paulirish merged commit 162ab75 into master Jun 11, 2019

paulirish deleted the jsoninlr branch June 11, 2019 20:25

snyk-bot mentioned this pull request Mar 21, 2020

[Snyk] Upgrade lighthouse from 5.1.0 to 5.6.0 godaddy/lighthouse4u#13

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

proto: update processForProto method signature, string -> LH.Result #9016

proto: update processForProto method signature, string -> LH.Result #9016

paulirish commented May 21, 2019

brendankenny commented May 21, 2019

brendankenny commented May 21, 2019

brendankenny left a comment

brendankenny May 21, 2019

brendankenny May 21, 2019

brendankenny May 21, 2019

brendankenny May 21, 2019

paulirish Jun 5, 2019

brendankenny Jun 6, 2019

connorjclark May 21, 2019

paulirish Jun 5, 2019

connorjclark Jun 6, 2019

This comment has been minimized.

brendankenny left a comment

brendankenny Jun 6, 2019

brendankenny Jun 6, 2019

patrickhulce Jun 7, 2019

brendankenny Jun 7, 2019

brendankenny Jun 6, 2019 •

edited

Loading

brendankenny Jun 6, 2019

brendankenny Jun 6, 2019

googlebot commented Jun 7, 2019

patrickhulce left a comment

patrickhulce Jun 7, 2019

googlebot commented Jun 11, 2019

proto: update processForProto method signature, string -> LH.Result #9016

proto: update processForProto method signature, string -> LH.Result #9016

Conversation

paulirish commented May 21, 2019

brendankenny commented May 21, 2019

brendankenny commented May 21, 2019

brendankenny left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

This comment has been minimized.

brendankenny left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

brendankenny Jun 6, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

googlebot commented Jun 7, 2019

patrickhulce left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

googlebot commented Jun 11, 2019

brendankenny Jun 6, 2019 •

edited

Loading