Add Prettier GitHub workflow

[jazzsequence]

Fixes #9082

Summary

per #9163 (comment) and #9163 (comment):

• Adds/updates ESLint. This was added as part of the initial implementation which has been removed. ESLint was left because we'll probably use it again in the future.
• Adds a new npm run lint script in package.json
• Updates the README.md to note how to run ESLint locally or fix all style issues with Prettier (using the existing npm run format command)
• Updates the Prettier config to use JS-based configuration and splits the difference between the old/existing config and the new config in 4ba6420
• Adds a new Prettier GitHub action to run the linter when any *.js file in src/ is affected by a pull request and only on the changed files.
  • Prettier-formatted files affected by this are then committed back to the repository by the robot and a comment is left in the PR that files were changed (see test prettier gh action #9180 (comment) for an example)

[stevector]

The prettier docs discourage using eslint-plugin-prettier as the method of executing the prettier check: https://prettier.io/docs/en/integrating-with-linters.html

Here's a summary video: https://www.youtube.com/watch?v=Cd-gBxzcsdA

I haven't yet watched the longer talk: https://www.youtube.com/watch?v=sSJBeWPIipQ&t=0s

I think we should first configure prettier in isolation, and secondarily configure ESLint.

[jazzsequence]

When I dug into Prettier, I discovered that the whole point of it is to edit files. This puts it at odds with reporting that there are linting issues as opposed to fixing those linting issues. ESLint is a linter and, in this context, it uses the ruleset established by Prettier as the rules it checks against.

I can remove ESLint, but then we're back to changing files rather than simply reporting that there are problems. I could just not commit those changes back to the PR, and report a failure if files were changed by Prettier, but it seems like that maybe defeats the purpose of the tool.

[jazzsequence]

New idea:

• remove ESLint
• run Prettier on PRs. it will change files. the GH action branch will now be ahead of the PR branch.
• run a git diff against the changes Prettier made
• post a comment back on the PR saying "these files have linting issues"
• (optional) maybe output the actual diff in the PR comment as well?

[stevector]

I link that idea, and I'd be fine with the same flow for ESLint, I think we can start with just prettier though (up to you if you'd rather remove ESLint or keep it and add a separate action for it (or add on to the same Action)).

Back to my comment here: #9082 (comment) I was initially hesitant about CI making the change/commit for us because I feared it'd supplant a learning opportunity. But, I see the potential for learning in this flow

• I'm doing development work in a branch
• I push/make a PR
• CI finds and fixes whitespace/etc with a new commit
• I push again
• Push rejected because of conflicts
• I pull and learn

[jazzsequence]

swinging back around to this.

1. Let's keep ESLint. We'll probably use it in the future.
2. Let's pull the ESLint action out.
3. Let's add a Prettier action that runs on changed files in PRs

• If files were changed, it will commit the change back to the PR.
• If it commits back to the PR, it posts a message back to the PR that looks like this: Move cookie settings inside the pantheon environment check wordpress-composer-managed#151 (comment)

4. ESLint checks can come after this workflow. In that way, ESLint would check all the things that Prettier couldn't fix automatically, as well as checking already fixed code.

I had originally thought of closing this PR and starting fresh, but if we're keeping ESLint (which I think would be a good idea), I'll just back out the ESLint action and replace it.

[wiz-inc-b08cf2810f]

Wiz Scan Summary

Scan Module						Total
IaC Misconfigurations	0	0	0	0	0	0
Vulnerabilities	0	13	10	2	0	25
Sensitive Data	0	0	0	0	0	0
Secrets	0	0	0	0	0	0
Total	0	13	10	2	0	25

View scan details in Wiz

To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension.

[jazzsequence]

Example robot comment and change: #9180 (comment)

[jazzsequence]

Made the requested changes and the Prettier workflow still seems to be working as expected (see #9180 (comment)).

I'm going to close that other test PR since I think I'm done with the testing, this should be good for you to use @stevector.