Configure postcss formatting after stylelint and stylelint-config-standard update

Actionable title

This is reported as a regression caused by updating Stylelint to 15, which was committed on July 17, 2023.

I spot-checked the first three files in the merge request, and they are change code that was in place prior to the Stylelint changes on July 17, 2023, so it looks like this MR is making changes and enforcing rules that were enforced by any Stylelint config in core. Some of these changes look nice, but they'd need to be proposed as changes to the configured standard, as they do not appear to be regressions.

Also worth noting, in Stylelint's "Significant changes" page for version 15 it points out

The deprecated rules will still work in this release (with a deprecation warning). In preparation for the next major release, when we'll remove the rules from Stylelint, we suggest:

. So while it is true these rules are deprecated and we should prepare for their removal, they should currently work as they did in earlier versions.

Prettier is definitely more strict and opinionated than Stylelint. As #6 says the bad formatting was previously there in many cases and Stylelint did not consider it a problem. While we now use Prettier for formatting PostCSS output, I don't think we ever applied the Prettier rules to unprocessed module CSS or the source *.pcss.css files.

If we *are* going to do this we should change the Prettier command in package.json:

    "prettier": "prettier --write \"./**/*.js\"",

to

    "prettier": "prettier --write \"./**/*.css\" \"./**/*.js\"",

(there is also module CSS that is never run through PostCSS, as well as *.pcss.css files)

Preparation for Stylelint 16 is happening in #3407211: [PP-upstream] Update stylelint(-config-standard) to latest versions (major bump)

There is also ongoing work to update the CSS coding standards and perhaps an option is to adopt Prettier for opinionated formatting?

Guess this needs frontend manager to pick which proposal

Overall I think we should just do this as it is only whitespace and quoting fixes, and makes all our CSS more consistent - if our compiled CSS uses prettier then why shouldn't our base CSS use it too?

However I think we can improve some comment placements, so added some feedback.

Spotted a few things in the MR I'd like updated, but hopefully nothing major. Overall this looks like a good addition by adding CSS support to the prettier functionality we're already accustomed to with our JS files, and the formatting changes are not too jarring.

Blocker resolved, follow up to reuse .prettierrc

Added feedback to the MR. It is all trivial other than one thing, and even the non-trivial one shouldn't be too demanding. Overall looks good and looking forward to rtbcing.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Appears to be some open threads if they can closed or marked complete.

Can the follow up mentioned in #40 be added also

MR appears to need a rebases.

Moving to NW for those 3 items.

Been using that config standard on most of my projects and will say like it a lot :)

It's a +1 for me but will leave in review for @bnjmnm as the frontend framework manager.

Re the media query comments #56

Positioning comments in each individual weird CSS is clearly outside of this task.

I think it belongs in the scope of this issue as the formatting changes implemented by this issue changes the position of these comments. I think having them on the same line or above a media query is similarly useful, having them underneath the MQ declaration makes them less so. If there are any specific ones that are particularly difficult to reposition, removing is also OK.

So for > me < to provide FEFM signoff, I want to see those media query PX comments positioned above. That said, if another FEFM is fine with it I will not protest that decision. I'm not comfortable approving as-is, but if one of my peers is that's fine by me.

about #60 given that this is an automated MR, I'd be reluctant to introduce manual changes on top of it. I did it for the once() replace patch and don't recommend it because of the difficulty to reroll. IMO The comments were placed awkwardly to begin with, so it make sense that an automated fix would place them not where we want.

Given that this is an automated patch, I'm fine with the comments in this issue but a follow-up needs to be created to move them either above or before the opening bracket.

Since we'll use prettier for css, we might want to enable css file rewrites in the prettier command of our package.json. Ok with a follow-up for that since we'll need to exclude a bunch of files/directories from this auto-formatting and it'd make all this longer.

I'm committing a bunch of issues with css changes to make the RTBC queue go down, so we'll have to reroll that just before commit.

I think we should address #10 from @longwave in a follow-up as the command yarn prettier currently makes changes even if we are on HEAD. Opened #3444587: Add CSS to prettier command and fix core/misc/jquery.form.js to be ignored

Committed 1fbf9f5 and pushed to 11.x. Thanks!

Needs backport to 10.4.x and probably 10.3.x too.

Created an MR against 10.4.x and ran the fixer...

Didn't know we had a 10.4 branch going now. But rerun for it seems fine

btw is a follow up still needed mentioned in #30 or framework manager approval since it was committed to 11.x already?

@smustgrave - @nod_, a frontend framework manager rtbc'd this issue in #65

Committed and pushed 5c9cc42046 to 10.4.x and 306ab17ec7 to 10.3.x. Thanks!

Backported to 10.3.x as major bug fix.