-
Notifications
You must be signed in to change notification settings - Fork 9.3k
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
proto: update processForProto method signature, string -> LH.Result #9016
Changes from 7 commits
c508f1f
455a20b
204c0cf
3bf14de
2ed7231
3a49ae2
83debc0
1fe5e33
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -24,9 +24,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 | ||
* @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>} | ||
*/ | ||
async function runLighthouseInLR(connection, url, flags, lrOpts) { | ||
const {lrDevice, categoryIDs, logAssets, configOverride} = lrOpts; | ||
brendankenny marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
@@ -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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yeah, probably just drop this line. At worst it's just extra work, and is just as assumed as every other property on There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. should it instead throw if output is set to anything other than 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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 ...but there are several possible things on |
||
|
||
let config; | ||
if (configOverride) { | ||
|
@@ -52,22 +53,17 @@ async function runLighthouseInLR(connection, url, flags, lrOpts) { | |
|
||
try { | ||
const runnerResult = await lighthouse(url, flags, config, connection); | ||
if (!runnerResult) return; | ||
if (!runnerResult) throw new Error('Lighthouse finished without a runnerResult'); | ||
|
||
// pre process the LHR for proto | ||
if (flags.output === 'json' && typeof runnerResult.report === 'string') { | ||
// 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. | ||
runnerResult.lhr.artifacts = runnerResult.artifacts; | ||
runnerResult.report = JSON.stringify(runnerResult.lhr); | ||
} | ||
|
||
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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this comment is inherited but is pretty confusing here since it appears to refer entirely to stuff outside of LH? e.g. If it's helpful for users of lr, though, seems ok to keep |
||
if (logAssets) { | ||
// @ts-ignore - Regenerate the report, but tack on the artifacts. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. maybe regenerate was referring to what it used to be doing? what about just |
||
runnerResult.lhr.artifacts = runnerResult.artifacts; | ||
} | ||
|
||
return runnerResult.report; | ||
// pre process the LHR for proto | ||
return JSON.stringify(preprocessor.processForProto(runnerResult.lhr)); | ||
} catch (err) { | ||
// If an error ruined the entire lighthouse run, attempt to return a meaningful error. | ||
let runtimeError; | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -16,11 +16,12 @@ const fs = require('fs'); | |
*/ | ||
|
||
/** | ||
* @param {string} result | ||
* Transform an LHR into a proto-friendly, mostly-compatible LHR. | ||
* @param {LH.Result} lhr | ||
* @return {LH.Result} | ||
*/ | ||
function processForProto(result) { | ||
/** @type {LH.Result} */ | ||
const reportJson = JSON.parse(result); | ||
function processForProto(lhr) { | ||
const reportJson = JSON.parse(JSON.stringify(lhr)); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yeah I prefer avoiding mutation too. if the few ms is worth the change, I'd suggest renaming the method to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. the type error (failure in travis) is because this whole function is operating on an Need to keep the |
||
|
||
// Clean up the configSettings | ||
// Note: This is not strictly required for conversion if protobuf parsing is set to | ||
|
@@ -95,7 +96,7 @@ function processForProto(result) { | |
|
||
removeStrings(reportJson); | ||
|
||
return JSON.stringify(reportJson); | ||
return reportJson; | ||
} | ||
|
||
// @ts-ignore claims always false, but this checks if cli or module | ||
|
@@ -113,9 +114,9 @@ if (require.main === module) { | |
|
||
if (input && output) { | ||
// process the file | ||
const report = processForProto(fs.readFileSync(input, 'utf-8')); | ||
const report = processForProto(JSON.parse(fs.readFileSync(input, 'utf-8'))); | ||
// write to output from argv | ||
fs.writeFileSync(output, report, 'utf-8'); | ||
fs.writeFileSync(output, JSON.stringify(report), 'utf-8'); | ||
} | ||
} else { | ||
module.exports = { | ||
|
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.
make sure you aren't accidentally still passing in
output: 'html'
and doing all that extra work :)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.
Added a comment.. i dont think we need a stronger check.
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.
yeah, I meant just double check existing code, definitely don't need a check in the code