Skip to content

core(fr): add base fraggle rock snapshot runner#11748

Merged
patrickhulce merged 5 commits into
masterfrom
fr_runner
Dec 8, 2020
Merged

core(fr): add base fraggle rock snapshot runner#11748
patrickhulce merged 5 commits into
masterfrom
fr_runner

Conversation

@patrickhulce

Copy link
Copy Markdown
Collaborator

Summary
Builds on the work of #11623 #11633 #11685 #11742 to add the base fraggle rock runner for snapshot mode. A very basic form of snapshot mode is now runnable with this PR. See the end-to-end puppeteer tests for the example.

const puppeteer = require('puppeteer')
const {snapshot} = require('lighthouse/lighthouse-core/fraggle-rock/api.js')
 
const browser = await puppeteer.launch()
const page = await browser.newPage()
await page.goto('http://example.com')
await page.click('body')
const {lhr, artifacts} = await snapshot({page})
console.log('A11y score was', lhr.categories.accessibility.score)

Related Issues/PRs
See #11622 and #11313 for the larger context.

@patrickhulce patrickhulce requested a review from a team as a code owner December 2, 2020 18:39
@patrickhulce patrickhulce requested review from adamraine and removed request for a team December 2, 2020 18:39
@google-cla google-cla Bot added the cla: yes label Dec 2, 2020

@connorjclark connorjclark left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

quick pass but this LGTM

Comment thread lighthouse-cli/test/fixtures/static-server.js Outdated
Comment thread lighthouse-cli/test/fixtures/static-server.js Outdated
@@ -227,6 +232,7 @@ if (require.main === module) {
console.log(`offline: listening on http://localhost:${offlinePort}`);

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

one day we should split this off into a smoke-static-server-entry.js or something ..

Comment thread lighthouse-core/fraggle-rock/api.js Outdated
Comment thread lighthouse-core/fraggle-rock/api.js
Comment thread lighthouse-core/fraggle-rock/api.js
Comment thread lighthouse-core/test/fraggle-rock/api-test-pptr.js Outdated
Comment thread lighthouse-core/test/fraggle-rock/api-test-pptr.js Outdated
Comment thread lighthouse-core/test/fraggle-rock/api-test-pptr.js Outdated
Comment thread types/config.d.ts
options?: {};
} | {
implementation: typeof Gatherer;
implementation: ClassOf<Gatherer.GathererInstance>;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

What does changing this do? typeof Gatherer already is a ClassOf<Gatherer.GathererInstance>

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Comment thread types/gatherer.d.ts
type PhaseResult_ = void|LH.GathererArtifacts[keyof LH.GathererArtifacts]
export type PhaseResult = PhaseResult_ | Promise<PhaseResult_>

export interface GathererInstance {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

same here. The js class is the base class and the interface. Duplicating it here doesn't seem to do more with the type and adds to maintenance/distancing types from jsdocs, etc

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Decoupling the implementation and the interface is the goal here to distinguish the new from the old and differentiate which gatherers support which models of execution in a relatively trivial and lightweight way.

Is there a counter proposal in there I'm missing for how incremental transition for gatherers will be supported? I'm happy to move the docs to the interface if that's what you're asking.

Comment thread types/config.d.ts
implementation: ClassOf<Gatherer.GathererInstance>;
options?: {};
} | {
instance: InstanceType<typeof Gatherer>;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

this is working around an old bug and should be able to just be instance: Gatherer, fwiw

const puppeteer = require('puppeteer');
const StaticServer = require('../../../lighthouse-cli/test/fixtures/static-server.js').Server;

jest.setTimeout(90 * 1000);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

90_000 y'all, step into the future :)

@@ -0,0 +1,84 @@
/**

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

if this ends up expanding to a bunch of new smoke tests, are you thinking about moving them somewhere else/called somehow else instead of in the midst of all the (mostly) unit tests?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

called somehow else, yes definitely 👍

moved somewhere else, no wasn't planning on it.

Comment thread lighthouse-core/fraggle-rock/api.js Outdated
artifacts[artifactName] = artifact;
}

return /** @type {LH.Artifacts} */ ({...baseArtifacts, ...artifacts}); // Cast to drop Partial<>

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I assume you're already thinking about how these types are mostly useless (sometimes worse than useless) in a world where we can't usually assume they're all actually there...

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Important to note this section was just copied from our existing gathering so it's not a degradation :)

I have not invested significant time on ideating how to improve the types here, no. I don't really consider the pre-existing temporary lie of LH.Artifacts at the runner level to be high on the list of type migrations that need to be done to get FR off the ground. Do you think this type flaw we have today is much more important in the FR world to warrant addressing soon?

Co-authored-by: Brendan Kenny <bckenny@gmail.com>
* @param {LH.Gatherer.GathererInstance} gatherer
* @return {gatherer is LH.Gatherer.FRGathererInstance}
*/
function isFRGatherer(gatherer) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Are all FR gatherers going to support snapshot mode?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

No, not all, see full compat table for which ones, but the next step after #11759 is the TODO that's here about using gatherer.meta to annotate whether a gatherer supports it or not.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

The name isFRGatherer makes it sound like this will detect FR gatherers, but it's used to detect snapshot support on L60. WDYT of renaming this to something like isFRSnapshotGatherer?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

The name isFRGatherer makes it sound like this will detect FR gatherers

Excellent, that's exactly what it's supposed to be doing :) purely a type guard on whether a gatherer instance supports the FR gatherer properties.

but it's used to detect snapshot support on L60

I consider this function not detecting snapshot support at all which is why the TODO is there. Any suggestion for alternative wording there to make it clearer? Snapshot detection support is 2-3 PRs away from being fixed and won't affect any results in the meantime.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think this issue has more to do with me misunderstanding the comment on L59 than the comment's wording. It's fine to leave as is :)

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

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants