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

extension: access core through module instead of Runner #5855

Merged
merged 1 commit into from Aug 17, 2018

Conversation

brendankenny
Copy link
Member

@brendankenny brendankenny commented Aug 17, 2018

Makes the extension (and devtools/psi) access lighthouse-core through the module interface instead of directly calling Runner.run(). With the last few simplifications to flags/settings/config, this refactor is now really simple and means we have a single core interface for all our platforms.

Works by allowing a Connection to be passed into lighthouse() instead of always using a desktop ChromeProtocol connection. This is something we have previously discussed with the puppeteer team to make #4403 easy, so it seems like a good move.

@paulirish I think this will also ease other refactors you've talked about for all the runLighthouseIn* methods

* @return {Promise<LH.RunnerResult|undefined>}
*/
async function lighthouse(url, flags = {}, configJSON) {
async function lighthouse(url, flags = {}, configJSON, connection) {
Copy link
Member Author

Choose a reason for hiding this comment

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

if we feel like this is going to become a never-ending list of optional arguments, we could put connection inside an object (overrides? or...something).

OTOH we don't want to go back to flags, settings, and options objects passed into every function :)

Copy link
Collaborator

Choose a reason for hiding this comment

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

4️⃣. 0️⃣ 😄

Copy link
Member Author

Choose a reason for hiding this comment

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

4️⃣. 0️⃣

ha. Just to be clear, ambiguous smiley face, this should be fine since it's just an addition to our API, not a change, right?

Copy link
Collaborator

Choose a reason for hiding this comment

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

oh, well since all of them are optional and you didn't like the idea of flags + options (I mostly agree), I thought you meant collect all of the arguments into a single argument options object which I like for 4.0

in the interim, I see no huge win from making connection an object with just connection since we'd like to make as much configurable from the config as possible, so this seems fine as-is to me

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.

seems good to me!

@@ -131,6 +131,9 @@ gulp.task('browserify-lighthouse', () => {
.ignore('rimraf')
.ignore('pako/lib/zlib/inflate.js');

// Don't include the desktop protocol connection.
bundle.ignore(require.resolve('../lighthouse-core/gather/connections/cri.js'));
Copy link
Collaborator

Choose a reason for hiding this comment

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

score!

let runnerResult;
try {
runnerResult = await lighthouse(url, flags, config, connection);
} finally {
Copy link
Member

Choose a reason for hiding this comment

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

l33t

@paulirish
Copy link
Member

this is so great.

@brendankenny brendankenny merged commit d103157 into master Aug 17, 2018
@brendankenny brendankenny deleted the extindex branch August 17, 2018 21:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants