I have a couple of things left to do, but @ryelle I think this is ready for a first look!

Remaining items (might add to this list):

• Don't use the config file if a --config is not present (right now this logic is based on the presence of the css-audit.config.js file and it's getting in the way)
• Make sure all of the audits work - most do
• Make sure the html format works and the template gets the property value data
• Rename one of the run.js files

Bonus feature:

• Ability to show categories for the property-values in the HTML version (maybe have a "title" key in the config object or something)

I pulled some of the fixes here out into master:

• c706bb9: ESLint: Allow console commands, remove inline exceptions
• 896de68: Audits: Add audit key to media queries & property values
• dc1cdd6: Remove unused CSS file

Instead of creating runAuditsFromConfig & runAuditsFromCLIArgs, what about creating getArg/getArgs overlays, which get the property from the CLI, and fall back to the config file if it exists? Right now, the filename for reports isn't working since it still uses getArgFromCLI, but it could just use getArg to get the filename wherever it's defined.

@ryelle This is ready to go in! There are a few things remaining that I think will be best in follow up PRs given how long this one has been open:

• Support multiple audit configurations e.g. wp-admin and other-project
• Option in the CLI to bypass the configuration file - right now if no corresponding arg exists in the CLI, whatever is in the configuration file will be respected. If that is a big set of audits, it is cumbersome to only run a single audit.
• Support "short names" for property-value audits - see screenshot below.

@ryelle Thanks for the review - feedback addressed! I removed the excessive property-values from the audit until we decide how we will work them in.

Will the values used in the config file for property-values be changed before merge? It looks like test cases, but I just want to check 🙂

I had copied what was in the CSS audit Google Doc - these are what we will want to see eventually but as we have seen, there's some additional thinking to do! I updated it to include just one property value for font-size.

I noticed an additional effect of the Property Values navigation issue: Because those report sections all have id="property-values" all of the Property Values nav links just jump to the first section. This could also be fixed once we have a short-names fix