-
-
Notifications
You must be signed in to change notification settings - Fork 28
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
Use fraggle rock API for conducting lighthouse tests #44
base: master
Are you sure you want to change the base?
Conversation
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.
This looks promising.
Could you attach documentation and relevant examples to understand the changes?
Sure, was currently updating the readme with examples. Will also attach relevant links that were used as references in this PR. |
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.
woahh nice 🚀
Hey @abhinaba-ghosh |
I will be testing this today and release a new version. |
Hey @asambstack sorry for the delay. Could you rebase your branch and resolve the conflicts? |
@asambstack any updates on this? Really looking to get this feature into package! |
Hey @abhinaba-ghosh The way lighthouse works with a puppeteer page is that it first creates a session object that acts as a wrapper around a puppeteer session. One of the things that lighthouse does with a puppeteer page is to attach event listeners to it (ref). This is possible due to the fact that puppeteer exposes a connection method to the CDP session object it has created (ref) which is an extension of an event emitter. This connection class exposed by puppeteer emits different events whenever the state of the webpage changes, for eg. Target.attachedToTarget / Target.detachedFromTarget. Even playwright emits the exact same events since these are CDP events, however this connection class doesn’t exist in case of playwright (ref). Meaning, to make this work with lighthouse, we would need to create a custom adapter connection class that acts as a bridge between playwright and lighthouse (ref). Will take a look into the feasibility, can discuss if you've any approaches in mind. |
@asambstack i took the code from this PR const patchPageObject = (page) => {
page.target = function () {
return {
createCDPSession: async function () {
const session = await page.context().newCDPSession(page);
session.connection = () => new events.EventEmitter();
return session;
},
};
};
}; Tried on my own project - and so far it works fine for me, even with page navigations initiated by user and webrtc trafic on the pages. Will keep you updated in case will see some issues |
); | ||
const newValues = Object.keys(results.lhr.categories).reduce( | ||
let results; | ||
if (process.env.LH_BROWSERSTACK == 'true') { |
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.
Would you mind updating the readme with this addition? Thanks
@asambstack apologies for a delayed response. Are we still considering moving forward with this PR? |
@asambstack @abhinaba-ghosh any updates on this? Would be cool to have this merged |
In the legacy lighthouse flow, a browser needs to be started with remote debugging port enabled and lighthouse starts testing by firing CDP commands over this RDP. Lighthouse team has been working on the fraggle rock API with flow support and several API changes (see: GoogleChrome/lighthouse#11313). This also includes a navigation API that can connect to existing puppeteer page instance for performing lighthouse tests.
By modifying the playwright object slightly, we can utilise the fraggle rock API for performing lighthouse tests.
Pros
playwright-lighthouse
, authenticated workflows will not break.Changes
patchPageObject
method for patching playwright pagecdpPort
param, moved util methods toutil.js