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

clients: simplify viewer build process #6426

Merged
merged 1 commit into from
Oct 31, 2018
Merged

clients: simplify viewer build process #6426

merged 1 commit into from
Oct 31, 2018

Conversation

brendankenny
Copy link
Member

Quick one-off to get viewer matching the clients after #6344 and #6295.

This eliminates gulp (we similarly barely used it here), moves the build script to build/, writes the output of the viewer build process to dist/viewer/, and there's no longer a need for yarn install-all.

dist output is exactly the same as master except that for some reason in viewer.js we end up with a file-level use strict instead of a scattering of function-level use stricts. Not sure why that happened (I assume there's an uglify setting), but it's strictly better, to that's fine :)

I'd argue for shortening lighthouse-viewer/ to viewer/ and possibly moving into clients/ while we're still pre-v4. Viewer is arguably a client but it also arguably dilutes that definition (currently a file that bundles all of lighthouse core), so we may or may not want to do that.

Also, we could get rid of uglify from viewer and use the same simple babel "minification" we use on the other bundles. It's only adds 15KB over 233KB (or 5KB over 51KB after gzip) to lose uglify. OTOH, we could leave the same until someone comes along and redoes our bundling/minification step.

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.

huzzah no more install-all 🎉

@@ -4,7 +4,7 @@ npm-debug.log
.vscode
.tmp

dist
Copy link
Collaborator

Choose a reason for hiding this comment

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

is there significance to this?

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 had lighthouse-viewer/dist left after this PR from an earlier build and it'll just stay there since it's gitignored. This will kind of alert that it's unnecessary now, but otherwise not much significance :)

}
}

run();
Copy link
Collaborator

Choose a reason for hiding this comment

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

I was about to write something along the lines of shame we have to have all this code, but then I saw that it's even fewer lines than the gulpfile 😆

@@ -70,6 +66,9 @@
"build-proto-roundtrip": "cd proto/scripts && PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=cpp PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION_VERSION=2 python json_roundtrip_via_proto.py"
},
"devDependencies": {
"@firebase/app-types": "0.3.1",
Copy link
Collaborator

Choose a reason for hiding this comment

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

😬

Copy link
Member Author

Choose a reason for hiding this comment

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

😬

yeah, this is only for the types. We use so little of it, maybe we should make our own types version locally

@@ -224,7 +224,6 @@ git clone https://github.com/GoogleChrome/lighthouse

cd lighthouse
yarn
yarn install-all
Copy link
Collaborator

Choose a reason for hiding this comment

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

🎉

const fs = require('fs');
const path = require('path');
const {promisify} = require('util');
const readFileAsync = promisify(fs.readFile);
Copy link
Collaborator

Choose a reason for hiding this comment

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

just curious, is there a particular reason we're using the async versions in scripts?

Copy link
Member Author

Choose a reason for hiding this comment

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

just curious, is there a particular reason we're using the async versions in scripts?

just a vague sense that we don't have to block on reading/writing, but just tried it (still on an SSD) with all sync and the files are so small/the build is so quick, it makes zero difference :) With await now they're roughly interchangeable, so it doesn't matter to me. Want to switch?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Nah it's fine, I just tend to use the sync ones for scripts to not mess with the promisification and async in scripts when everything is pretty much serial anyway and was curious if there was another benefit

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.

WFM!

@brendankenny
Copy link
Member Author

screen shot 2018-10-30 at 16 15 53

oh it's so pretty, all in one place @paulirish

@paulirish paulirish merged commit 9615070 into master Oct 31, 2018
@paulirish paulirish deleted the buildviewer branch October 31, 2018 01:12
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.

3 participants