Add CSS (JS?) code formatting automation

Description of the need

It'd be nice to add an automation (GitHub Action) that formats code nicely for us in PRs. This'd not only make sure code is easy-to-read and consistent, but would prevent the back-and-forth, nit-picky reviews where we ask contributors to add some whitespace here, fix this comment to not overflow 80 characters, etc.

Proposed solution

As discussed in #2785 (comment), code linters seem to be moving away from 'stylistic' changes and just focusing on flagging/fixing bugs in code. In other words, a linter will warn you about a missing parentheses, but it won't flag whitespace or line-length issues.

This is where code formatters (or 'prettifiers') come in. I recommend we decide on which we'd like to use and then set it up as a GH action to run on PRs.

Alternatives that have been considered

We can always stick with our current system of having a documented coding style, and pointing contributors to that when we mark their PRs as 'needs work', but I don't think that's an ideal solution for reasons I'll get into below...

Draft of feature description for Press Release (1 paragraph at most)

Backdrop now automatically flags and/or fixes code formatting issues in pull requests for readability and consistency.

---

Related:

• #5245
• #2785

Prettier is one option, however it's opinionated, meaning it has its own set of rules by which your code will be formatted and you can't really change them.

Initially this struck me as a bad idea. I mean, we have a set of coding standards that we've developed (inherited), so we'd need an automated code formatter to abide by them, right? But then as I read the Why Prettier? page, I started coming around to the idea of using an opinionated formatter...

Here are the problems of our current system and how something like Prettier would fix that for us:

• Developers debate over how code should be formatted (yes, even after it's already been documented: Fixed: Remove blank lines before @file docblocks. #4824) - this is because we're human and we're unique, emotional beings.
  • Prettier sets a standard for code formatting that's fully automated (no emotion or back-and-forth debates involved).
• Newcomers excited about getting their first PR merged can be disappointed with the review process when it comes to styling (e.g. the nit-picking about whitespace, line lengths, etc.) and lose motivation for further contributions as a result.
  • Prettier automates the formatting of code, so this low-level reviewing of code is no longer needed (less work for reviewers and less frustration for contributors).
• Developers have different coding styles and levels of experience - different coding styles mean more fixing needed to bring it to consistency, and less experience may mean more hesitation in making PRs that publicly show your inexperience.
  • Prettier makes all code look the same, so despite developers writing code differently, it all ends up being consistent, and developers who aren't as experienced feel better about their PRs since they're formatted the same as everyone else's.
• We maintain our own coding standards. These may need updating/changing over time and can be a cause of controversy for the community. They also need to be fully and definitively documented to be useful.
  • Prettier does away with the need for our own coding standards. Our standards going forward would just be "the way Prettier does it, which happens automatically", so no need to separately document everything.

Like I said, I'm becoming more open to the idea of using an opinionated code formatter, but still open to a discussion about other, customisable formatters if people want to suggest any...

[indigoxela]

This suggestion seems to go a step further than #5245 (where we tried to add a GHA to automatically comment on (but not fix) coding standard violations.

@indigoxela Yep. Coding standards (that affect bugs, functionality, tests, etc.) are different than stylistic changes. These can (and should, IMO) be fixed automatically. Who wants to see tests fail, and have to manually update their PR, because of a missing space, etc.?

[bugfolder]

I love the idea that the nit-picky things like extra spacing or off-by-one indents would be automatically fixed without me having to go back and edit code and do a re-run of tests. But I'd also like to know what I missed, for future reference. Would the GHA issue a report of what it did? Or (even better) make its changes via a commit to the source of the PR, or something like that?

[jenlampton]

@bugfolder I'd like to see it apply a PR to your PR that you then need to review + approve. That way they are automatically fixed, but still needs a human to approve the fixes :)

Here's a PR that adds the 'Prettier' code formatter as a GitHub action: backdrop/backdrop#4035

It just adds a new commit to PRs that cleans up any core CSS/JS files the PR affects.

For example, see my test PR here: https://github.com/BWPanda/backdrop-prettier/pull/3
Someone wants to add some CSS to the Seven theme, but it's badly formatted, so this action cleans it up and adds a new commit (you can see the original commit here: https://github.com/BWPanda/backdrop-prettier/pull/3/commits/63f55c865c6a70c6bdadf126841ebdf6307edc4e).

I know people said above that they'd like the ability to review the changes to their PR before accepting them, but I don't see the need for this. If we decide to use Prettier's coding standards, or even if we find another solution that uses our own coding standards, in what situation would we want a PR against code that decides not to adhere to those standards? If people simply want to see what changes are being made to their PR, they can do so by looking at the commit (e.g. https://github.com/BWPanda/backdrop-prettier/pull/3/commits/d6574fd802a0a38b9469eae53aead11c6bebc7f8).