Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
stylelint released a new major version (https://github.com/stylelint/stylelint/releases/tag/16.0.1).
Related:
stylelint-config-standard followed suit. (https://github.com/stylelint/stylelint-config-standard/releases/tag/35.0.0)
stylelint-order only bumped a minor version (https://github.com/hudochenkov/stylelint-order/releases/tag/6.0.4)
Steps to reproduce
$ yarn outdated
Proposed resolution
$ yarn add -D stylelint stylelint-config-standardfor bumping the major versions of these two dependencies$ yarn upgrade stylelint-orderfor minor bumpingstylelint-order- Bump minimum version of node.js in
/core/package.json(https://stylelint.io/migration-guide/to-16#removed-support-for-nodejs-le...) - Delete removed rules from
core/.stylelintrc.json(https://stylelint.io/migration-guide/to-16#removed-deprecated-stylistic-...). These arefunction-whitespace-afterandmax-line-length. Both were unused anyway, since they defined asnull
Remaining tasks
_If_ we can and want to ship this with drupal 10.2.0, I think we need to decide if we want to wait on stylelint-formatter-gitlab to be stylelint:^16-ready, in order to keep our nice code-quality overview in GitLab or (temporarily) go back to the situation before #3387503: Move Gitlab linting steps to main job where CSS linting failures are reported as test-failures.
User interface changes
API changes
Data model changes
Release notes snippet
Issue fork drupal-3407211
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
spokjeComment #3
spokjeComment #5
spokjeComment #6
spokjeComment #7
spokjeComment #8
spokjeSo the current state of the MR uses
stylelint-junit-formatter.I also opened https://gitlab.com/leon0399/stylelint-formatter-gitlab/-/issues/3 to try and get
stylelint-formatter-gitlabworking withstylelint16 and upwards.Putting this on NR the get some input on:
- if we want to try and get this into 10.2.0
- if so, are we prepared to (temporarily) fallback to using
stylelint-junit-formatterand going back to test-errors instead of codequality.Comment #9
smustgrave commentedThe rules being removed does prettier automatically catch those now?
Comment #10
spokjeNot quite, but good question.
-
stylelinthas loads of rules, but enables none of them by default.-
stylelint-config-standardenables a bunch of them with some community-defined, sane defaultsDrupal uses a lot of those
stylelint-config-standardrules, but overrules some of them with other defaults, and disables others.The latter one is of interest here: When there's a
"[rule-name]": nulldefined incore/.stylelintrc.json, it _should_ meanstylelint-config-standard-enabled rule, Drupal turns it off. See https://stylelint.io/user-guide/configure/#rules, first bullet-point. (More on the _should_ below).The rules that are removed in this issue (
function-whitespace-afterandmax-line-length), were both defined as null, so were turned off in Drupal, so no need for replacement.Now to the _should_: Turns out during all updates of
stylelintandstylelint-config-standardwe didn't pay much attention to rules that were dropped at some point fromstylelint-config-standardbut still being turned off in ourcore/.stylelintrc.json.Turning things off that aren't on in the first place is just silly.
Opened #3408129: Sync up core/.stylelintrc.json and stylelint-config-standard to get
core/.stylelintrc.json,stylelintandstylelint-config-standardback into sync.TLDR; There's no need to do anything with the deleted rules in this issue, Drupal wasn't using them.
Thanks for asking though, since it made me dive in deeper and found some cruft to remove in a follow-up issue :)
Comment #11
smustgrave commentedThanks for explaining!
Comment #12
longwaveThank you for explaining the changes in #10.
As this breaks our current CI integration because
stylelint-formatter-gitlabis not yet compatible, I think we should hold off on committing this for a while - there are no pressing changes here and to me this can wait until 10.3.