-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
feat(config): add extends lighthouse:full #2557
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.
small meta discussion: thoughts about extending the other way, sort of like eslint: having lighthouse:default
defining everything that goes in itself and then lighthouse:full
extending the default and adding any non-default gatherers/audits to it?
I'm not sure if there's much to argue for that, though. The only advantage I can think of is that you'd be able to see all of what runs in a default LH run in one place instead of having to cross reference between two files. It might also make optimizing the default run easier, but I don't have much to back that up.
Any thoughts on advantages one way or the other?
otherwise should be fine after updating for the config.js changes that landed |
I do! That way would make the diff cleaner :) I'll give it a whirl |
1951f8f
to
9e3a7a7
Compare
this feels a lot better, PTAL :) |
Yeah that was a great call. I'm happy with this. |
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.
LGTM too
if we start including a lot more audits in the repo that aren't included in the default config we may want to split |
My intention is to add a checkbox in devtools to run these extra/slow audits so we'd still need them to be browserified, I actually was second guessing if not having them in the default config would get them in there at first haha :) |
oh, I was going to guess that at first, but isn't e.g. coverage kind of redundant in devtools when there's a better interface in other panels? I guess we could link between the report and those panels... |
last step to support #2518 and the forthcoming js coverage PR
split into several commits for easier viewing