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

add gulp recipe (wip) #1886

Merged
merged 6 commits into from
Mar 30, 2017
Merged

add gulp recipe (wip) #1886

merged 6 commits into from
Mar 30, 2017

Conversation

denar90
Copy link
Contributor

@denar90 denar90 commented Mar 21, 2017

Actual implementation is done, but I faced same issue

events.js:161
      throw er; // Unhandled 'error' event
      ^

Error: connect ECONNREFUSED 127.0.0.1:9222

as on pwmetrics.

Here some debug of this issue if someone is interested - paulirish/pwmetrics#63 (comment)

So, after solving this one it will be ready to merge.


P.S. Maybe @addyosmani will be interested to make webpack recipe :)

@denar90
Copy link
Contributor Author

denar90 commented Mar 22, 2017

Just realize that, before, chrome launcher has to be started. It's running in cli stuff. Is it worth to have recipes and stuff here or just in scope of pwmetrics?
cc @paulirish

@addyosmani
Copy link
Member

I'd be interested to understand the scope of interest in build-tool integration docs :) I need to rev https://github.com/addyosmani/webpack-lighthouse-plugin to latest if we want to reference elsewhere in docs.

@denar90
Copy link
Contributor Author

denar90 commented Mar 24, 2017

It's really nice to have good recipes/build-tool integration docs for people who wanna implement Lighthouse for CI. For some of them it's critical to have implementation example...


function handleOk() {
connect.serverClose();
process.exit(0);
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if we can add something here to check the score and pass/fail based on that? This will always exit cleanly if running LH succeeds.

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 thought that all LH log will be shown in a console.
E.g. in pwmetrics for pass/fail we use smth like smokehouse.
What would you suggest?
Maybe reviewer (if we talking about project where LH will be injected) will look at CI and say it has bad trace, but 😒 , who does that..., so I dunno...
But I think bringing smokehouse as user feature will be kinda overhead...

Copy link
Contributor

Choose a reason for hiding this comment

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

I was thinking from the perspective of a user that wants to "fail the build" if their LH score drops to something too low or if they want to use the score in some way. Maybe just add the results object param to handleOk(results) and stick a // TODO: use lighthouse results after connect.serverClose();?

return connect.server({
root: '../public',
livereload: true,
port: port
Copy link
Contributor

Choose a reason for hiding this comment

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

We tend to just use the key if the var name is the same:

  livereload: true,
  port
}

const connect = require('gulp-connect');
const lighthouse = require('../../../lighthouse-core');
const perfConfig = require('../../../lighthouse-core/config/perf.json');
const port = 8080;
Copy link
Contributor

Choose a reason for hiding this comment

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

const PORT


const gulp = require('gulp');
const connect = require('gulp-connect');
const lighthouse = require('../../../lighthouse-core');
Copy link
Contributor

Choose a reason for hiding this comment

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

If the idea is that we have cut/paste examples, users of this example will write this:

const lighthouse = require('lighthouse');
const perfConfig = require('lighthouse/lighthouse-core/config/perf.json');

package.json Outdated
@@ -34,7 +34,8 @@
"chrome": "node ./lighthouse-cli/manual-chrome-launcher.js",
"fast": "npm run start -- --disable-device-emulation --disable-cpu-throttling --disable-network-throttling",
"smokehouse": "node lighthouse-cli/test/smokehouse/smokehouse.js",
"deploy-viewer": "cd lighthouse-viewer && gulp deploy"
"deploy-viewer": "cd lighthouse-viewer && gulp deploy",
"gulp-example": "gulp --gulpfile docs/recipes/gulp/gulpfile.js --cwd docs/recipes/gulp"
Copy link
Contributor

Choose a reason for hiding this comment

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

IMO, we leave this as a documented example and not add it to core. Instead, you can create a directory for this recipe (docs/recipes/gulp-example) and stick a new package.json in there. Having everything in a single directory will also be future proof. I suspect we'll have a bunch more recipes in the future. Having a folder for each would be good.

add pkg in recipes

add install recipes script
Copy link
Contributor

@ebidel ebidel left a comment

Choose a reason for hiding this comment

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

Good changes. I ran the example and it works great. Just a few more things.

};

const launchChrome = function() {
launcher = new (ChromeLauncher.ChromeLauncher || ChromeLauncher)();
Copy link
Contributor

Choose a reason for hiding this comment

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

is there a reason to do this? If you const ChromeLauncher = require('lighthouse/lighthouse-cli/chrome-launcher'). ChromeLauncher;, then you can just use directly.

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 dunno, it was just dumb copy/paste from https://github.com/paulirish/pwmetrics/blob/master/lib/index.js#L122
maybe @paulirish knows more...

return connect.server({
root: '../public',
livereload: true,
PORT
Copy link
Contributor

Choose a reason for hiding this comment

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

port: PORT

const runLighthouse = function() {
const url = `http://localhost:${PORT}/index.html`;
const ligthouseOptions = {}; // available options - https://github.com/GoogleChrome/lighthouse/#cli-options
lighthouse(url, ligthouseOptions, perfConfig)
Copy link
Contributor

Choose a reason for hiding this comment

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

return lighthouse(url, ligthouseOptions, perfConfig)

};

gulp.task('lighthouse', function() {
Promise.resolve(launchChrome()).then(_ => {
Copy link
Contributor

Choose a reason for hiding this comment

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

No need for Promise.resolve(). launchChrome() returns a promise.

launchChrome().then(_ => {
  connectServer();
  return runLighthouse();
});

@@ -0,0 +1,12 @@
{
Copy link
Contributor

Choose a reason for hiding this comment

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

I still prefer if we put everything in docs/recipes/gulp/ so this example is standalone. When we have more recipes in the future, it'll be less confusing on what npm dependencies, scripts, etc. are required for each.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agree 👍 Just misunderstood your point

"devDependencies": {
"gulp": "^3.9.1",
"gulp-connect": "^5.0.0",
"lighthouse": "^1.6.3"
Copy link
Contributor

Choose a reason for hiding this comment

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

maybe less restrictive on the LH version. ^1.x might be ok, so users get the latest lighthouse when they try this demo.

package.json Outdated
@@ -46,6 +47,7 @@
"google-closure-compiler": "^20161201.0.0",
"gulp": "^3.9.1",
"gulp-concat": "^2.6.1",
"gulp-connect": "^5.0.0",
Copy link
Contributor

Choose a reason for hiding this comment

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

remove

package.json Outdated
"install-cli": "cd ./lighthouse-cli && npm install",
"install-extension": "cd ./lighthouse-extension && npm install",
"install-viewer": "cd ./lighthouse-viewer && npm install",
"install-recipes": "cd ./docs/recipes && npm install",
Copy link
Contributor

Choose a reason for hiding this comment

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

IMO, we don't need to necessarily make recipes runnable from the main package. I see them as more as documentation examples that users can copy/paste or run themselves. Installing these extras will also slow down our good buddy Travis.

* Handle ok result
* @param {Object} results - Lighthouse results
*/
const handleOk = function() {
Copy link
Contributor

Choose a reason for hiding this comment

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

function(results) {

*/
const handleOk = function() {
disconnectServer();
// TODO: use lighthouse results for checking your performance expectations
Copy link
Contributor

Choose a reason for hiding this comment

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

Add a console.log(results); so users see something when they run the example.

Copy link
Member

@brendankenny brendankenny left a comment

Choose a reason for hiding this comment

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

nice! excited to get a set of recipes together

@@ -0,0 +1,79 @@
'use strict';
Copy link
Member

Choose a reason for hiding this comment

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

need a license header

/**
* Connect to server
*/
const connectServer = function() {
Copy link
Member

Choose a reason for hiding this comment

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

nit: maybe startServer and stopServer instead of connectServer and disconnectServer?

const lighthouseOptions = {}; // available options - https://github.com/GoogleChrome/lighthouse/#cli-options
return lighthouse(url, lighthouseOptions, perfConfig)
.then(handleOk)
.catch(handleError);
Copy link
Member

Choose a reason for hiding this comment

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

also a nit: should .then(handleOk).catch(handleError); be moved into the gulp.task('lighthouse') block? So it would be

gulp.task('lighthouse', function() {
  launchChrome().then(_ => {
    connectServer();
    return runLighthouse()
      .then(handleOk);
  }).catch(handleError);
});

or something? Seems to make more sense there than in runLighthouse

@@ -0,0 +1,17 @@
<!DOCTYPE html>
Copy link
Member

Choose a reason for hiding this comment

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

@@ -1,5 +1,21 @@
'use strict';

/**
* Copyright 2016 Google Inc. All rights reserved.
Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry, 2017 :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

no bother :)

@@ -1,4 +1,19 @@
<!DOCTYPE html>
<!--
* Copyright 2016 Google Inc. All rights reserved.
Copy link
Contributor

Choose a reason for hiding this comment

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

2017

Copy link
Member

@brendankenny brendankenny left a comment

Choose a reason for hiding this comment

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

LGTM2. Thanks!

If you have (or have ideas for) more helpful recipes, please keep them coming :)

@brendankenny brendankenny merged commit 6898d09 into GoogleChrome:master Mar 30, 2017
@denar90
Copy link
Contributor Author

denar90 commented Mar 30, 2017

@ebidel @brendankenny thanks for grounded review and merging stuff.

If you have (or have ideas for) more helpful recipes, please keep them coming :)

Definitely 👍

@denar90 denar90 deleted the recipes branch March 30, 2017 21:26
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.

4 participants