-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
core(lhr): remove debugString, add explantion/errorMessage #5132
Conversation
Not sure if my approval here is really needed but I'll give a LGTM anyways :P |
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.
lighthouse-core/runner.js
Outdated
|
||
if (audit.warnings.length) { | ||
const prefixedWarnings = audit.warnings.map(msg => `${audit.description}: ${msg}`); | ||
lighthouseRunWarnings.push(...prefixedWarnings); |
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.
all warnings are pushed to the toplevel warnings?
relatedly: i haven't seen a top level warning in the report in a long time. :)
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.
all warnings are pushed to the toplevel warnings?
correct, I figure we can always change this without breaking LHR changes later if we don't like it/prefer to flag the individual audits, buuuuuut as you point out...
relatedly: i haven't seen a top level warning in the report in a long time. :)
agreed I can't remember seeing one naturally, so seems like a good time to try this out
only thing I can think of we might want to change is that the warnings entries are objects like {message: string}
in the LHR so we can later add {level: }
etc if we want
@@ -99,7 +99,8 @@ describe('PerfCategoryRenderer', () => { | |||
assert.ok(oppSparklineElement.title, 'did not set tooltip on sparkline'); | |||
}); | |||
|
|||
it('renders the performance opportunities with a debug string', () => { | |||
// TODO(phulce): verify these don't happen anymore | |||
it.skip('renders the performance opportunities with a debug string', () => { |
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.
in a branch of mine, i handle this case.
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.
cool beans, in this case it's referring to the fact that it should exclusively be an "error" and that an explanation isn't really possible anymore (the error case is covered by the case below)
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.
so, verified?
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.
yes indeed, removed
"debugString": "Audit error: Required RobotsTxt gatherer did not run.", | ||
"displayValue": "", | ||
"errorMessage": "Audit error: Required RobotsTxt gatherer did not run.", | ||
"warnings": [], |
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.
can we leave warnings undefined if there are none?
same thing with displayValue, tbh. :)
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 sgtm 👍 @brendankenny agree?
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.
@brendankenny agree?
yeah, sounds good
Hmmm strange @paulirish they're working fine for me, is this merged with some of your branches perhaps and mixing with the single-use displayValue bug? |
@paulirish diff is ~100 lines smaller with undefined warnings/displayValue 🎉 |
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.
I dig this. Over to brendan.
fc9a3cb
to
c5d522e
Compare
travis/appveyor seem real confused |
c5d522e
to
5757ed4
Compare
yeah I don't think they rebuild on change of base, just force pushed |
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.
overally the change looks good and I like how much clearer things are for our bug vs their bug vs just a result from the audit :) A few major things for how we handle these different outputs:
-
it's great to start using
displayValue
for things that are display values, but it does expose a weakness with how we display them. It's definitely harder to scan across to the value for the audit vs just having it right below
old:
new:
(and it's even wider across when not shrunk by github) -
Separating the warnings from the audits seems like a regression from the status quo in most of the
warnings
cases added here. Having a list of images we can't reencode at the top of the report or (in the case ofsample_v2.json
) a warning that sometarget=_blank
anchors may be outgoing but we can't tell, seems like noise at the top of the report and is lost as valuable context at the individual audit level (where you probably want to be warned that the audit may have been unable to comprehensively run its test).
Maybe having log levels for warnings make sense, and only things that audits flag as super important get moved to the top-level box, and everything else stays at the audit level?
@@ -99,7 +99,8 @@ describe('PerfCategoryRenderer', () => { | |||
assert.ok(oppSparklineElement.title, 'did not set tooltip on sparkline'); | |||
}); | |||
|
|||
it('renders the performance opportunities with a debug string', () => { | |||
// TODO(phulce): verify these don't happen anymore | |||
it.skip('renders the performance opportunities with a debug string', () => { |
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.
so, verified?
@@ -113,7 +113,8 @@ describe('CategoryRenderer', () => { | |||
category.description = prevDesc; | |||
}); | |||
|
|||
it('renders audits with debugString as failed', () => { | |||
// TODO(phulce): decide what to do about these cases |
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.
whats' the decision?
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.
updated the comment. this is what's up for debate re: toplevel warnings
currently the test simply doesn't apply anymore since all warnings are stuck into toplevel for display
@@ -182,7 +182,7 @@ class RobotsTxt extends Audit { | |||
if (!status) { | |||
return { | |||
rawValue: false, | |||
debugString: 'Lighthouse was unable to download your robots.txt file', | |||
explanation: 'Lighthouse was unable to download your robots.txt file', |
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.
is this a failure case on our part or the site's?
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.
depends on what you mean by "our part" it could be because the server aborted the request/bad server/etc or it could be because the network failed, either way it seems to belong in explanation instead of errorMessage since there's nothing we would change code-wise, it's expected behavior
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.
I guess this is the nuance we should expose so the user has some recourse (either file a bug on lighthouse or know how to start debugging their site). Really a bug on robots-txt gatherer so fine to leave
debugString = 'Lighthouse was unable to determine the destination ' + | ||
'of some anchor tags. If they are not used as hyperlinks, ' + | ||
'consider removing the _blank target.'; | ||
// TODO(phulce): make this message better with anchor.outerHTML |
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.
old message had a lot more explanation :)
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.
fixed
@@ -167,7 +166,7 @@ class Audit { | |||
result.rawValue = true; | |||
} | |||
|
|||
if (result.error) { | |||
if (result.errorMessage) { |
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.
time to rework re: #5128 (comment) ?
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.
discussed in person, todo assigned to @brendankenny :)
some of the TODOs clearly seem like for the future (e.g. |
yeah mostly just called out for discussion which it has sparked so 👍 only one remaining is in response to your other comments which we just discussed in person
We've definitely entered highly subjective territory here because I disagree 😄 Either way, we can always change where we put/color/highlight displayValue later on so we'll pickup discussion of best display value designs in a separate issue. |
filed #5153 @brendankenny 👍 |
yeah, it was just a comment on the display of |
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.
warnings/displayValue discussion moved to #5153
My only other concern would be making a warning out of e.g. every image in uses-optimized-images.js
, but we can take that up in #5153ish
I am SUPER jazzed about this change. I think it cleans up the intention behind everything A LOT and is extra nice. There is no more debug string exposed at the audit level (manifest-parser still returns a debug string from gatherer but we can clean that up later). Existing debug strings got recategorized into one of
displayValue
- for cases like appcache where we just communicated the name of the thing we founderrorMessage
- when the message was a true error message/failure casewarnings
- for when the message was just a warning. This is the biggest behavioral change in the PR, the warnings are now collected and displayed in the top-level warnings instead of popping the specific audit into failing. I request that you only consider if warnings should be exposed per-audit in the LHR for this PR and not discuss the display mechanism we can always change how the warnings manifest in the report later, so let's just focus on the breaking-LHR-relevant change.explanation
- the default case if the debugString didn't obviously fit into the other 3, these are currently displayed exactly as debugString was before, so no real impact other than name change. I have ideas for how to change the display but we can 🚲 🏠 that another dayNOTE: relies on #5128 and conflicts with #5130