Update to Stylelint 14

Decide which new rules we should fix and which we should ignore.

I think we can do that in follow-ups.

These look great. Thanks @longwave

Are the commit-code-check.sh changes working? I tried checking the DrupalCI output and it looks like only files that were changed by the patch were actually tested.

Let's open a follow-up to discuss how to stop individual checks when a general scan all the things has occurred. We have this for JS and PHPCS too so a generic solution might be better.

Ahh makes sense. Could someone file follow-up for #12?

Created #3260373: Only scan individual files for PHPCS / eslint / Stylelint if necessary

Committed f1a00d1 and pushed to 10.0.x. Also committed the 9.x patch to 9.4.x. Thanks!

I think we should backport this to 9.3.x too to make backporting patches easier. Any thoughts on that?

Discussed with @longwave and @catch and we didn't see that there would be problem cherry-picking to 9.3.x since Stylelint is a dev dependency. There are couple of CSS changes so I think it's better to have the active branches as consistent as possible so that backports remain straight forward.

HEAD has been failing on 9.3.x and 9.4.x with PHP 7.3 since Jan. 26. This is the only issue that was committed to 9.3.x between Dec. 29 and yesterday, so it seems like the only possible cause unless there was an upstream change on CI that is causing the fail.
Edit: That was a git log weirdness, from a commit being cherry-picked much later.

https://www.drupal.org/pift-ci-job/2305316

So, here's a revert to test whether HEAD will pass.

Additionally, this issue should not have been backported to 9.3.x under our allowed changes policy, because even dev dependency updates disrupt build pipelines. Especially since it's a major version update. Normally we would only do such an update in the production branch if there were a security issue. So regardless of whether this is the cause of the HEAD fail, it should probably be reverted from 9.3.x and not re-committed there.

The CI output for #21 does not make any sense -- it says that custom commands failed, but then all the checks individually are listed as passing. Running sh ./core/scripts/dev/commit-code-check.sh locally also passes.

Only other thing I can think of is to revert both commits that have been made on 9.3.x in January, in case there's some Stylelint 14-compatible changes in the more recent CKE5 commit that are somehow not being reported correctly on CI.

If this also fails with weirdness then I might just revert both commits and see what happens. Since HEAD is failing anyways it can't get worse. We can always recommit them.

OK, the "Custom commands failed" also failed in HEAD with this reverted (even with the issue after it reverted too), so I recommitted both of them. Reading over the console output, this is the only actual error message:

23:16:47 Error: No files matching the pattern "/var/www/html/core/themes/claro/css/classy/components/indented.css" were found.
23:16:47     at /var/www/html/core/node_modules/stylelint/lib/standalone.js:212:12
23:16:47     at processTicksAndRejections (internal/process/task_queues.js:97:5)
23:16:47 

I don't know why that is happening with #21 and #23 both when they are the two most recent commits on the branch and it didn't happen until I reverted them, but we need to figure out how to fix it so that this can be reverted from 9.3.x per the second paragraph of #21.

(Meanwhile, I found the actual probable source of the PHP 7.3 regressions in #3172166: Element::properties() produces notices if given an array with integer keys -- just missed it in the git log because of weird commit date ordering from cherry-picks being out of order vs. 9.4.x. Sorry for the noise about that part, but we still do need to make this 9.4.x only.) :)

We need to keep the --allow-empty-input argument in the stylelint command for the stylelint command to pass when CSS files copied from Classy are being changed in Claro and Olivero.

@longwave Can you file a followup for that? I just want to get this reverted now so that we're not committing to it with no way to back out in a patch release today.

Alright, committed the revert patch to 9.3.x after comparing it with a local revert. Thanks @longwave!

In the future, it might be better to split an issue like this into those sorts of separate scopes to begin with.

Finally, all dependency updates should be tagged for the release notes, especially if it's outside the normal expectations of what would get a dependency update in a given release. So even if we agreed the whole enchilada should go in 9.3.3, the issue should have had both the "9.4.0 release notes and "9.3.3 release notes") issue tags. Thanks!

Restoring original title and 9.4.x branch now that the revert's in.

Dependency update should also always be in the release notes. It sounds like this might want a CR too, for the improvements to linting etc.?

Thanks @longwave!

This is also a change from 10.0.0-alpha1, so adding it to the alpha2 release notes list.