Skip to content
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

report: create faux psi report #12815

Merged
merged 30 commits into from
Aug 11, 2021
Merged

report: create faux psi report #12815

merged 30 commits into from
Aug 11, 2021

Conversation

paulirish
Copy link
Member

@paulirish paulirish commented Jul 21, 2021

I wanted a test page where there are two LHRs, like in PSI. This helps surface the peculiar behavior we get with tabs and element-screenshot-overlay and how it's gotta live outside the tab body.

here 'tis: https://lighthouse-git-faux-psi-googlechrome.vercel.app/%E2%8C%A3.psi.english

@paulirish paulirish requested a review from a team as a code owner July 21, 2021 17:03
@paulirish paulirish requested review from adamraine and removed request for a team July 21, 2021 17:03
@google-cla google-cla bot added the cla: yes label Jul 21, 2021
@adamraine
Copy link
Member

adamraine commented Jul 21, 2021

I noticed clicking on an audit filter in the desktop tab doesn't do anything on the desktop audits, but does change the filter for the mobile tab.

Edit: ope this is a PSI bug

@paulirish
Copy link
Member Author

paulirish commented Jul 21, 2021

I noticed clicking on an audit filter in the desktop tab doesn't do anything on the desktop audits, but does change the filter for the mobile tab.

Edit: ope this is a PSI bug

heh. well. thats exactly what this lil stupid report is for. :)
kinda perfect, tbh.

update: PR to fix up in #12817

Copy link
Collaborator

@connorjclark connorjclark left a comment

Choose a reason for hiding this comment

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

I wanted a test page where there are two LHRs, like in PSI. This helps surface the peculiar behavior we get with tabs and element-screenshot-overlay and how it's gotta live outside the tab body.

Can you put that as a comment in one of the PSI test "asset" files?

const lhr = /** @type {LH.Result} */ (require('../../lighthouse-core/test/results/sample_v2.json'));
const {LH_ROOT} = require('../../root.js');

const DIST = path.join(LH_ROOT, `dist/now`);

(async function() {
// Must build before importing report-generator (or indirectly through lighthouse)
await buildreport.buildStandaloneReport();
Copy link
Collaborator

Choose a reason for hiding this comment

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

why remove yarn build-report && from yarn now-build ? it's simpler than doing the imports here in the right order.

the CLI options could be expanded to build psi report on a flag

Copy link
Member Author

@paulirish paulirish Jul 23, 2021

Choose a reason for hiding this comment

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

hmm.. i don't know what you do, but if i'm working on the report this is my watch equivalent:

find report | entr node lighthouse-core/scripts/build-report-for-autodeployment.js

i heart entr. (but i can't && in that command or whatever so... the combo of the two commands is a problem).

i guess an alternative would be a new yarn build-dist-reports script that does build-report followed by this. that'd be fine.

wdyt?

Copy link
Collaborator

@connorjclark connorjclark Jul 23, 2021

Choose a reason for hiding this comment

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

but i can't && in that command or whatever so.

Do it like this:

find report | entr bash -c "ls && echo hi"

wdyt?

the extra commands make it hard to follow. go back to yarn build-report && node lighthouse-core/scripts/build-report-for-autodeployment.js && yarn build-viewer && yarn build-treemap && cp -r dist/gh-pages dist/now/gh-pages and just use the bash trick above ?

I assume you don't just do find report | yarn now-build because of all the extra stuff going on there that it takes a bit longer... 7s (vs 2s) for a watch is rough

package.json Outdated
@@ -54,6 +55,7 @@
"cli-unit": "yarn unit-cli",
"viewer-unit": "yarn unit-viewer",
"watch": "yarn unit-core --watch",
"watch:report": "find report | entr yarn build-dist-reports",
Copy link
Collaborator

Choose a reason for hiding this comment

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

sgtm

/**
* @return {string}
*/
function generatePsiReportHtml() {
Copy link
Member

Choose a reason for hiding this comment

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

this definitely seems kind of weird in build-report-for-autodeployment.js and possibly hard to keep up to date when changes happen to report-generator, but I also like keeping it simple like this while we iterate on report/overall build story

* Drops the LHR to only one, solo category (performance), and removes budgets.
* @param {LH.Result} lhr
*/
function tweakLhrForPsi(lhr) {
Copy link
Member

Choose a reason for hiding this comment

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

should this matter? Shouldn't it just be able to take a regular LHR and just ignore the stuff it doesn't want? Or is this more a matter of giving it the data it will actually get in practice for a more realistic deployment?

Copy link
Member Author

Choose a reason for hiding this comment

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

It shouldnt matter much, but I just wanted to the data to match what PSI would expect to see. I can't think of any real reasons why it'd matter (like full-page-screenshot being in another category or something).

package.json Outdated
@@ -54,6 +55,7 @@
"cli-unit": "yarn unit-cli",
"viewer-unit": "yarn unit-viewer",
"watch": "yarn unit-core --watch",
"watch:report": "find report | entr yarn build-dist-reports",
Copy link
Member

Choose a reason for hiding this comment

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

what happened to

sure lets just leave the entr stuff out of our scripts for now

?

@@ -24,6 +24,7 @@
"build-lr": "yarn reset-link && node ./build/build-lightrider-bundles.js",
"build-pack": "bash build/build-pack.sh",
"build-report": "node build/build-report.js",
"build-dist-reports": "yarn build-report && node lighthouse-core/scripts/build-report-for-autodeployment.js",
Copy link
Member

Choose a reason for hiding this comment

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

bike shed: what is build-dist-reports referring to? Just build reports that will be in dist/? Because it's also sample reports in particular. build-sample-reports?

Copy link
Collaborator

Choose a reason for hiding this comment

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

hehe me and paul were talking about the naming here...

  • build-dist-reports: Builds the report renderer and the reports for the Vercel deployment
  • build-report-for-autodeployment.js: Builds the reports for the Vercel deployment
  • now-build: The Vercel deployment used to be called "now". not anymore

some renaming is in order all around.

@@ -28,15 +28,23 @@ class ReportGenerator {
}

/**
* Returns the report HTML as a string with the report JSON and renderer JS inlined.
* @param {Object} object
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
* @param {Object} object
* @param {unknown} object

}

/**
* Returns the standaloe report HTML as a string with the report JSON and renderer JS inlined.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
* Returns the standaloe report HTML as a string with the report JSON and renderer JS inlined.
* Returns the standalone report HTML as a string with the report JSON and renderer JS inlined.

* @param {LH.Result} lhr
* @param {string} tabId
*/
async function distinguishLHR(lhr, tabId) {
Copy link
Member

Choose a reason for hiding this comment

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

can this be combined with what happens in tweakLhrForPsi?

Copy link
Member Author

Choose a reason for hiding this comment

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

i could but then i wouldn't have the single-category dist-report. but i really want that for local report dev. :)

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.

5 participants