wordpress / css-audit Goto Github PK

It's possible to manually trigger actions if they listen for a workflow_dispatch event.

Now that trunk merges don't trigger the report, it would be nice to be able to manually trigger a rebuild.

Consider adding a link back to the repo where the public/wp-admin.html is hosted. So users that may directly land on (and consequently Bookmark): https://wordpress.github.io/css-audit/public/wp-admin can find out where the project resides.

Pull request incoming. Thanks for creating this great tool!

For generating the HTML report, we need a way to specify groups of property-values for the reports. This was accomplished with the CLI table by re-running the command with different values, but for the HTML report, we want to get the audit data for multiple groups at one time. One idea for accomplishing this is to specify an external JSON config file that contains the groups of properties to be audited, and that can be passed to the property-values option to process.

A related need is for a higher level grouping of the output of the --property-values audit. For example, we would want the output of these audits to be under a "Typography" heading in the HTML report:

--property-values=font-size
--property-values=line-height
--property-values=font-weight

And similarly, these we might want to have under "Spacing":

--property-values=padding,padding-top,padding-bottom,padding-left,padding-right
--property-values=margin,margin-top,margin-bottom,margin-left,margin-right

This could also be accomplished with the external config approach, but maybe there are other ideas!

If we run this over a file, it should pull out any place where a property: value; repeats. For example, this should return [ 'border: 1px solid red' ].

.foo {
    padding: 20px;
    border: 1px solid red;
}
.bar {
    padding: 10px;
    border: 1px solid red;
}

Because trunk is protected now, the action bot can't commit to it.

Error: Error: Pushing to https://github.com/WordPress/css-audit
POST git-receive-pack (735 bytes)
remote: error: GH006: Protected branch update failed for refs/heads/trunk.        
remote: error: At least 1 approving review is required by reviewers with write access.        
error: failed to push some refs to 'https://github.com/WordPress/css-audit'

This is an idea to improve the colors audit. Core has a fixed color palette, so we could use that list to highlight colors that are not in the set (if any). The palette should work like an allowed-list, flagging anything not on the list.

For example: if #f00 is added, it will show up in the audit, but currently no indication that it shouldn't be there. There could be another section of the Colors report, which lists these non-allowed-list colors:

1. #f00 found in wordpress/src/wp-admin/css/admin-menu.css, line #33.

In most audits, it shows "Top 10 most used …". This was done to avoid overwhelming the CLI screen from too much information, given how large the results can be on core CSS (even just single reports, like colors).

For the new JSON output (--format=json), this does not need to be human readable, so we can return the full result set for all values.

This might need to change the way audits return report objects.

This came out of discussion around #7, but is a larger idea, hence new issue. The arguments we can pass via CLI are pretty long and generally not very clear. Instead, what if we had a config file (akin to webpack.config.js/eslintrc.js) to set up those rules? It could be a JS/JSON file that describes the desired report (format, audits, etc).

I'm thinking something like this for format, which kind of follows a babel-ish pattern for audits, where you can say the string name of the audit, or an array with the first item as the name, and second as arguments to the audit. This would also address the issue in #7 by allowing for repeating audits with different arguments.

Example:

{
	"format": "html",
	"filename": "wp-admin",
	"audits": [
		"colors",
		"important",
		"display-none",
		"selectors",
		"media-queries",
		[
			"property-values",
			{
				"options": [ "font-size" ]
			}
		],
		[
			"property-values",
			{
				"options": [
					"padding-top",
					"padding-bottom",
					"padding-left",
					"padding-right"
				]
			}
		]
	]
}

We could also allow for a simple file like this— though maybe we should rename all & recommended to preset:all & preset:recommended.

{
	"format": "cli-table",
	"audits": "recommended"
}

• Number of distinct media queries
• Instance counts of each
• [Maybe] Distinct sizes (ignoring if there's screen and …)
• [Maybe] Flag any media queries that are the same except for screen?

We need get all of the counts again without the .css.orig files, and we could update the Google Doc with the new counts, but it seems like we would benefit from having this data on Github so it is more shareable and we can keep track of history – is that something that could be part of this repo?

In order to automate this vs. manually copy/pasting the data as in the GDoc, it could work something like this (starting to test this out in this WIP PR):

• Refactor to return an object of the results that can be used in other scripts
• Refactor to move the CLI-specific contents to a cli.js
• Create a new CLI argument - css-audit ./wp-admin/* --all --generate-report=wp-admin
• --generate-report will output the audit results to an .html file inside public/wp-admin.html

Then public/ can be deployed on Github pages. Thoughts?

Add workflow_dispatch: to merge-trunk-to-report.yml

On https://github.com/WordPress/css-audit/actions the merge action displays as a yaml filepath rather than the specified name value:

I think this is because the name value includes a reserved character:
name: Merge trunk -> report

We'll want to keep the report up to date, so we should have some way of automatically regenerating the HTML report.

I'm assuming this will be a github action, but the trigger mechanism might need some thought. We'll want to update either on a fixed schedule, or after commits to WordPress/wordpress-develop, and after changes to this repo.

Past work committing back to the repo in a github action: https://github.com/WordPress/twentytwentyone/blob/trunk/.github/workflows/build.yml

Some tests to make sure the audits are counting things correctly would be good