Update prettier/PostCSS/stylelint for 11.2

🇮🇳India sd9121

🇮🇳India sd9121

Hi @longwave,

I have manually resolved all the CSS linting issues.
The merge request has been updated with these changes.
Please review the patch when you get a chance.

Thanks!

Ah, the weird :is() selectors have returned.

This was touched on in 📌 Update postcss* to latest releases Active , and the gist is that that while that selector might make some complex expressions more efficient, it makes simple ones with id selectors less so.

See comments #39 and #40 in the previous issue for more details.

@godotislate opened merge request.

OK put up MR 12216 which is just the commits from 12063 but with the prettier "2021" nesting rules added. The :is() selectors have gone away and the diff is significantly smaller now. Documentation says that the 2021 nesting rules will be removed eventually, so at some point (now?) a decision has to be made on what to do about the nesting rules behavior with :is(), but anyway MR 12216 is an option to kick the can down the road on that decision.

I think 🐛 Library: other group placed first Active is effectively a pre-duplicate now, so that probably can be closed with credit migrated here.

🇺🇸United States mherchel Gainesville, FL, US

Yeah, I was also wondering about the 'nesting-rules': { edition: '2021' },. Per the docs it defaults the the behavior of previous PostCSS nesting (which is not actually what browsers implemented).

The new rules (2024-02) cause the browser to accurately reproduce specificity by wrapping parent selectors in an :is(). This mimics the actual behavior of browsers (which basically wrap parent selectors in an :is()).

I really doubt the 2024-02 rules will cause any regressions, but it's impossible to be 100% sure unless we have some type of robust visual regression testing going on, which we don't.

My suggestion is to stick with the 2021 rules for now. Early on after 11.2, lets update to the 2024-02 rules, which will more accurately reproduce the specificity that browser do. Then we'll have several months to find any potential regressions.

After that, we should really see what's holding us back from shipping native nesting. A quick look at https://caniuse.com/css-nesting, shows that our supported browsers support it.

godotislate → changed the visibility of the branch 3523078-update-prettierpostcssstylelint-for to hidden.

nod_ → closed merge request !12216

🇫🇷France nod_ Lille

somehow doesn't cherry pick to 11.2.x

nod_ → committed ea0eb3ca on 11.x

Issue #3523078 by sd9121, longwave, godotislate, mherchel: Update...

🇫🇷France nod_ Lille

So there was this change made here:

index f61ca3a374a..7f9e7a4f9d7 100644
--- a/core/themes/claro/css/components/system-status-counter.pcss.css
+++ b/core/themes/claro/css/components/system-status-counter.pcss.css
@@ -31,8 +31,7 @@
     background-size: 40px;

     [dir="rtl"] & {
-      border-inline-end: 1px solid #e6e4df;
-      border-inline-start: 0;
+      background-position: left center;
     }

     @media (forced-colors: active) {

And this change made in 293fe02ea0887359199162e0ee9ff868e846b644 that was not backported to 11.2.x:

diff --git a/core/themes/claro/css/components/system-status-counter.pcss.css b/core/themes/claro/css/components/system-status-counter.pcss.css
index a5b139eabe4..f61ca3a374a 100644
--- a/core/themes/claro/css/components/system-status-counter.pcss.css
+++ b/core/themes/claro/css/components/system-status-counter.pcss.css
@@ -30,6 +30,11 @@
     background-position: right center;
     background-size: 40px;

+    [dir="rtl"] & {
+      border-inline-end: 1px solid #e6e4df;
+      border-inline-start: 0;
+    }
+
     @media (forced-colors: active) {
       background-color: canvastext;
       background-image: none;
@@ -37,10 +42,6 @@
       mask-position: right center;
       mask-size: 40px;
     }
-
-    @nest [dir="rtl"] & {
-      background-position: left center;
-    }
   }
}

which is causing the conflict in 11.2.x

@godotislate opened merge request.

I think 📌 Remove @nest from claro stylesheets Active needs to be ported into 11.2.x, because MR 12299 here against 11.2.x is failing for errors like these:
[{"type":"issue","check_name":"at-rule-no-deprecated","description":"Unexpected deprecated at-rule \"@nest\" (at-rule-no-deprecated)","content":{"body":"Error found in at-rule-no-deprecated. See https://stylelint.io/user-guide/rules/at-rule-no-deprecated for more details."},"categories":["Style"],"location":{"path":"themes/claro/css/components/breadcrumb.pcss.css"

Also, please bring over credit from 📌 Update postcss* to latest releases Active here.

I added the 📌 Remove @nest from claro stylesheets Active commits to MR 12299, and the MR passes now, so that was issue.

Moving to NR to kick off discussion about next steps. Should 📌 Remove @nest from claro stylesheets Active be backported to 11.2.x first, then this MR rebased?

🇫🇷France nod_ Lille

backported the issue, and rebased the MR

nod_ → committed 2d44347b on 11.2.x

Issue #3523078 by sd9121, longwave, godotislate, mherchel: Update...

🇫🇷France nod_ Lille

Was able to cherry pick after backporting the other issue

🇬🇧United Kingdom catch

nod_ → credited catch → .

🇨🇦Canada nickdickinsonwilde Victoria, BC (T'So-uke lands)

nod_ → credited nickdickinsonwilde → .

🇳🇿New Zealand quietone

nod_ → credited quietone → .

🇳🇱Netherlands spokje

nod_ → credited spokje → .

🇫🇷France nod_ Lille

porting credit

godotislate → closed merge request !12299

Created follow up per #11: 📌 Use latest rules for postcss-nesting Active

🇺🇸United States xjm

🇺🇸United States xjm

We need a brief release note here, including a mention of the nesting rules bit maybe with the link to the reference? And we can mention that the 2024 version will be used in a future release.

🇺🇸United States tim.plunkett Philadelphia

Took me a bit to track down why Project Browser's Stylelint started failing (due to usage of rgba()) , there was no CR. Idk if that's worth a full CR but it would be nice.

🇺🇸United States xjm

#35 sounds worthwhile also.

The stylelint release notes are somewhat opaque, but it looks like there were quite a few rules added between 16.11.0 and 16.19.1: https://github.com/stylelint/stylelint/releases. Do they all need documentation in the CR?

🇫🇷France nod_ Lille

AI powered release note

🇬🇧United Kingdom longwave UK

@godotislate actual changes to the standards are usually from stylelint-config-standard's major version updates, e.g. v38 added color-function-alias-notation: "without-alpha" rule which enforced the rgba to rgb change: https://github.com/stylelint/stylelint-config-standard/releases

Updated the release note a bit. Not sure we need a change record to document what an upstream dependency did?

🇺🇸United States xjm

@longwave I think the request for a CR was based on the idea that this broke PB, which happened against HEAD. A CR would have notified them; the release note is too late. Interesting conundrum though, for when dependencies force changes in core that also cause disruptions downstream...

🇺🇸United States xjm

In this case, since we're actually changing the content of many core stylesheets, I think we should go with the CR as well. It's not pure dep update. That said, even the pure dep update might still have broken PB, so it's still an interesting question. OTOH, very little is as bleeding-edge as PB.

🇺🇸United States xjm

🇺🇸United States smustgrave

Made a simple CR pulling from the release notes https://www.drupal.org/node/3530572 →

🇺🇸United States xjm

Thanks @smustgrave. I gave it a quick review and it reads well, although someone besides me should probably also review it (i.e. someone who knows CSS because I don't). 😅

Saving credit for the CR draft.

🇺🇸United States mherchel Gainesville, FL, US

CR looks

to me!

🇺🇸United States xjm

lol 🐅

Comment 23 days ago →