Skip to content

Conversation

@jckr
Copy link
Contributor

@jckr jckr commented Apr 12, 2021

Summary
This is in response to issue #11514. Currently, gather-runner can dedupe warnings if they are strings, however, they can also be of type LH.IcuMessage, and as a result several such warnings can appear in the final report.

In my previous PR #12351, that problem could appear:

image

Related Issues/PRs

@jckr jckr requested a review from a team as a code owner April 12, 2021 23:46
@jckr jckr requested review from patrickhulce and removed request for a team April 12, 2021 23:46
@google-cla google-cla bot added the cla: yes label Apr 12, 2021
@jckr jckr requested a review from connorjclark April 12, 2021 23:46
Copy link
Collaborator

@patrickhulce patrickhulce left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice work! thanks @jckr :)

const LighthouseRunWarnings = [];
for (const warning of baseArtifacts.LighthouseRunWarnings) {
// each entry in baseArtifacts.LighthouseRunWarnings can be a string or a LH.IcuMessage.
const stringifiedWarning = JSON.stringify(warning);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have the lodash.isequal package in our dependencies which does deep equality like what we're looking for here and isn't sensitive to ordering like a stringify approach is.

Given we tend to have very few warnings here, I'm not as concerned with preserving hashset time complexity :)

WDYT about switching to a LighthouseRunWarnings.some(existing => isDeepEqual(warning, existing) check?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i see what you mean. updating the branch

@patrickhulce patrickhulce self-assigned this Apr 13, 2021
@paulirish paulirish changed the title better deduping of warnings report: better deduping of warnings Apr 13, 2021
Copy link
Collaborator

@patrickhulce patrickhulce left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 💯

great stuff!

passContext.LighthouseRunWarnings.push(
...runWarnings,
...runWarnings,
// adding one of the warnings with keys in different order
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

// Take only unique LighthouseRunWarnings.
baseArtifacts.LighthouseRunWarnings = Array.from(new Set(baseArtifacts.LighthouseRunWarnings));

/** @type {(string | LH.IcuMessage)[]} */
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if you've already been introduced to this minor team war yet ;) but Array<T> vs T[] pops up quite a bit for us.

We typically let it go in reviews and don't have a firm policy on it, so it probably won't come up much again and you'll see mismatched examples throughout the codebase but just in case this was a casual usage and you don't have strong feelings yet, allow me to pitch you on Array<T> for complex, long, or namespaced type, and only use T[] when it's a primitive or simple non-namespaced type 😁 If you've already formed strong opinions here, feel free to ignore :)

@paulirish
Copy link
Member

looks like this is good to go.

the type change seems optional. i'm fine with either way.

@google-cla
Copy link

google-cla bot commented Aug 16, 2021

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

@google-cla google-cla bot added cla: no and removed cla: yes labels Aug 16, 2021
@paulirish
Copy link
Member

Heh, looks like @patrickhulce actually lifted this implementation when he landed c5fddd9#diff-19b3c3e228a1602f508fa6e6df814df9d1e45475f96894455df2f6eb08bf67baR85

However the test wasn't modified. So I've made this PR current and now it's just the test. \o/

@paulirish
Copy link
Member

@googlebot I consent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants