feat: support category and audit whitelisting#1988
Conversation
brendankenny
left a comment
There was a problem hiding this comment.
this looks like it's going to be great.
General things:
- I've seen the
:format used more for referencing special values (e.g.'lighthouse:default') rather than just giving the type of thing. Does it make more sense to haveonlyCategoriesandonlyAuditsproperties instead of the less explicitonlyprop? - We need to be clear about the hierarchy here (but where?). It's a little confusing that it's one or the other, category or audit, but not both. e.g. if you say
only: ["audit:service-worker", "category:pwa"], the category wins and you run all of the pwa category, not just theservice-workeraudit within it - definitely want warnings to the user about things like trying to do only an audit when you're also doing only the category that includes it (see above) and unknown audit/category names to catch misspellings and the like.
- tests! :)
lighthouse-core/config/config.js
Outdated
| * Filter out any unrequested categories from the categories object. | ||
| * @param {!Object<string, {audits: !Array<{id: string}>}>} categories | ||
| * @param {Array<string>=} categoryIds | ||
| * @param {Array<string>=} auditIds |
There was a problem hiding this comment.
looks like we missed this before and these should be {!Array<string>=}
lighthouse-core/config/config.js
Outdated
| @@ -344,14 +356,21 @@ class Config { | |||
| * Filter out any unrequested categories from the categories object. | |||
| "dobetterweb/tags-blocking-first-paint", | ||
| "dobetterweb/optimized-images" | ||
| ] | ||
| "extends": "lighthouse:default", |
There was a problem hiding this comment.
this is a lie depending on the current check just being truthiness of extends, right?
I'm fine with this too, but with the goal of having all config settings map to CLI flags that seemed slightly polluting. WFM if others agree to split though.
Agreed, this keeps it simple by being 100% additive so if it's listed in |
I'm fine with both and consider them equivalent from an ergonomics POV. |
|
this waiting on anything else? PTAL :) |
lighthouse-core/config/config.js
Outdated
| const categories = {}; | ||
|
|
||
| // warn if the category is not found | ||
| categoryIds.forEach(category => { |
There was a problem hiding this comment.
category -> categoryId
lighthouse-core/config/config.js
Outdated
| }); | ||
|
|
||
| // warn if the audit is not found in a category | ||
| auditIds.forEach(audit => { |
lighthouse-core/config/config.js
Outdated
| // warn if the category is not found | ||
| categoryIds.forEach(category => { | ||
| if (!oldCategories[category]) { | ||
| log.warn('config', `unrecognized category: ${category}`); |
There was a problem hiding this comment.
need a clearer way of saying this, since users will see it without context. Not sure what would be good though... maybe just unrecognized category in `onlyCategories`: ${category}?
lighthouse-core/config/config.js
Outdated
| }); | ||
|
|
||
| if (!foundCategory) { | ||
| log.warn('config', `unrecognized audit: ${audit}`); |
lighthouse-core/config/config.js
Outdated
| } | ||
|
|
||
| if (categoryIds.includes(foundCategory)) { | ||
| log.warn('config', `${foundCategory} category already includes "${audit}"`); |
There was a problem hiding this comment.
I'm not sure how to word this one either. ${audit} in `onlyAudits` already included by `onlyCategories` entry ${foundCategory}? Or something less terrible :)
| }); | ||
|
|
||
| assert.ok(config.audits.length, 'inherited audits by extension'); | ||
| assert.ok(config.audits.length < origConfig.audits.length, 'filtered out audits'); |
There was a problem hiding this comment.
could you do origConfig.categories.performance.audits.length + 1? Seems future compatible
| const auditCount = Object.keys(selectedCategory.audits).length; | ||
| assert.equal(config.passes.length, 3, 'incorrect # of passes'); | ||
| assert.equal(config.audits.length, auditCount, 'audit filtering failed'); | ||
| }); |
There was a problem hiding this comment.
tests for the new warnings would be good, too. log.events.addListener('warning', callback) can be an easy way to do that rather than going to the trouble of overriding log, like is done elsewhere in that file
| */ | ||
| window.runLighthouseForConnection = function(connection, url, options, categoryIDs) { | ||
| const newConfig = Config.generateNewConfigOfCategories(defaultConfig, categoryIDs); | ||
| const newConfig = Config.generateNewFilteredConfig(defaultConfig, categoryIDs); |
There was a problem hiding this comment.
should we switch this to just
const newConfig = {
"extends": "lighthouse:default",
"settings": {
"onlyCategories": categoryIDs
}
};
addresses burndown items for I/O #1937
usage to run just TTI, PSI, and the PWA audits