[dependabot]

Bumps @stylistic/stylelint-plugin from 5.3.1 to 6.0.0.

Release notes

Sourced from @​stylistic/stylelint-plugin's releases.

Release v6.0.0

This release brings a lot of changes. For a smoother update to it, use the migration guide.

Changed

The plugin now requires stylelint version 18.0.0 or higher.

Namespaces for custom syntaxes

The rules under their core names no longer read an SCSS or Less stylesheet, or a styled template: such a file now gets one warning naming the namespace that holds the same rules with the same options and documentation, and nothing else of it is checked. Where the namespace's copy of the rule is configured over the file, in an overrides block or through a preset, that copy reads it and the core name says nothing. An option a namespace's syntax cannot carry is refused there instead: Less refuses an at-rule name in upper case, so upper is an invalid option of @stylistic/less/at-rule-name-case, since a stylistic fix must never leave a file its compiler refuses.

Rename the rules in the overrides block that sets customSyntax — @stylistic/scss/indentation in place of @stylistic/indentation, and less or styled in place of scss for the other two. Nothing else in the configuration changes, and a namespace reads plain CSS exactly as the core does. A configuration that names no syntax anywhere is unaffected: such a file is parsed as CSS, which is the family the core's copies read, and it is read by them under the same names and with the same warnings as before.

The core is now written for plain CSS alone, so a construct only a preprocessor spells is read as the CSS it is: a Sass module (ns.$a), a placeholder selector (%a), a nested property (font: { … }), a comment opened by a double slash, an at-rule carrying neither block nor parameters, and a value opening with @. A plain CSS file spelling any of those may meet warnings it used to escape.

The new defineStylistic and defineStylisticOverride functions (see below) name the syntax once for the whole block, so the rules stay under their short names and you write no namespace at all.

A rule listed under two of these names over one stylesheet is now read once, by the copy of the stylesheet's own family — the core's over plain CSS, the namespace's over its syntax — and the other copies yield without a word; where the family's copy is not configured, the first listed copy whose namespace accepts the stylesheet reads it. A configuration listing the core and a namespace over the same files used to run every rule twice there and report every problem twice.

Expanding the scope of the rules

• The named-grid-areas-alignment rule now applies to the grid-template and grid properties too, and not only to grid-template-areas (see #45). Where your code spells those shorthands, the rule may start asking for corrections or writing them under --fix. For finer control use its new option (see below).

Independence from the order of the rules

Many rules now read the settings of other rules and what they will write in the same text, so what --fix leaves no longer depends on where the configuration lists a rule (see #352, #354, #355, #477, #502). A rule writing a line break, for one, asks the linebreaks rule which break to write, wherever that rule is listed. Where a neighbor's write changes whether the rule's own option asks anything at all, the text is read as the whole fix leaves it, and a file that needed a second --fix run rests on one. Expect some new autocorrections in your code.

End-of-line characters

The plugin now reads a line break the way PostCSS and Stylelint do: a line feed, alone or behind the carriage return of a Windows pair. A bare carriage return and a form feed are plain whitespace, so a file broken with either is one line to every rule about breaks, empty lines and multi-line lists, and no rule reports a position your editor cannot show. The linebreaks rule still tells \n from \r\n.

Passing over @charset

The at-rule-name-case, at-rule-name-space-after, at-rule-name-newline-after, at-rule-semicolon-space-before and string-quotes rules no longer warn about a @charset or write into it, in any spelling: the encoding declaration is a byte sequence the browser reads before parsing rather than an at-rule, and every other spelling of it is ignored. Stylelint's at-charset-rule-no-invalid rule judges the spelling instead, so a CSS file holding a @charset now gets one warning asking you to enable that rule where your configuration leaves it off. The unicode-bom rule under "always" now warns about the option itself over a CSS file whose first node is a @charset, since the mark would keep the declaration from working; set "never" or leave the rule unset for such files.

Conflicting settings

The plugin now refuses a configuration holding two settings that conflict with each other, such as value-list-comma-newline-after: "always-multi-line" beside value-list-comma-space-after: "always": the run stops with a configuration error naming both settings and what to change (see #743). Where your configuration holds such a pair, change one of the two as the message says, or turn one of them off. The types of defineStylistic refuse such a pair in the editor.

Added

New rules

• The aspect-ratio-notation rule, which specifies how the value of aspect-ratio is written (see #18).
• The declaration-block-single-line-max-declarations rule, which limits the number of declarations within a single-line declaration block (see #639). Stylelint 18 removes the rule of its own, and this one takes the same option, so a configuration moves it by renaming it to @stylistic/declaration-block-single-line-max-declarations. It reads more than Stylelint's did — the single-line block of an at-rule as well (see #640) — and it is autofixable, which Stylelint's never was (see #641).
• The value-slash-newline-before and value-slash-newline-after rules, which require a newline or disallow whitespace on either side of the same solidus (see #622).
• The value-slash-space-before, value-slash-space-after, media-feature-slash-space-before and media-feature-slash-space-after rules, which require a single space or disallow whitespace on either side of the solidus of a value or of a media feature's ratio (see #548).

New options

... (truncated)

Changelog

Sourced from @​stylistic/stylelint-plugin's changelog.

[6.0.0] — 2026–11–03

This release brings a lot of changes. For a smoother update to it, use the migration guide.

Changed

The plugin now requires stylelint version 18.0.0 or higher.

Namespaces for custom syntaxes

The rules under their core names no longer read an SCSS or Less stylesheet, or a styled template: such a file now gets one warning naming the namespace that holds the same rules with the same options and documentation, and nothing else of it is checked. Where the namespace's copy of the rule is configured over the file, in an overrides block or through a preset, that copy reads it and the core name says nothing. An option a namespace's syntax cannot carry is refused there instead: Less refuses an at-rule name in upper case, so upper is an invalid option of @stylistic/less/at-rule-name-case, since a stylistic fix must never leave a file its compiler refuses.

Rename the rules in the overrides block that sets customSyntax — @stylistic/scss/indentation in place of @stylistic/indentation, and less or styled in place of scss for the other two. Nothing else in the configuration changes, and a namespace reads plain CSS exactly as the core does. A configuration that names no syntax anywhere is unaffected: such a file is parsed as CSS, which is the family the core's copies read, and it is read by them under the same names and with the same warnings as before.

The core is now written for plain CSS alone, so a construct only a preprocessor spells is read as the CSS it is: a Sass module (ns.$a), a placeholder selector (%a), a nested property (font: { … }), a comment opened by a double slash, an at-rule carrying neither block nor parameters, and a value opening with @. A plain CSS file spelling any of those may meet warnings it used to escape.

The new defineStylistic and defineStylisticOverride functions (see below) name the syntax once for the whole block, so the rules stay under their short names and you write no namespace at all.

A rule listed under two of these names over one stylesheet is now read once, by the copy of the stylesheet's own family — the core's over plain CSS, the namespace's over its syntax — and the other copies yield without a word; where the family's copy is not configured, the first listed copy whose namespace accepts the stylesheet reads it. A configuration listing the core and a namespace over the same files used to run every rule twice there and report every problem twice.

Expanding the scope of the rules

• The named-grid-areas-alignment rule now applies to the grid-template and grid properties too, and not only to grid-template-areas (see #45). Where your code spells those shorthands, the rule may start asking for corrections or writing them under --fix. For finer control use its new option (see below).

Independence from the order of the rules

Many rules now read the settings of other rules and what they will write in the same text, so what --fix leaves no longer depends on where the configuration lists a rule (see #352, #354, #355, #477, #502). A rule writing a line break, for one, asks the linebreaks rule which break to write, wherever that rule is listed. Where a neighbor's write changes whether the rule's own option asks anything at all, the text is read as the whole fix leaves it, and a file that needed a second --fix run rests on one. Expect some new autocorrections in your code.

End-of-line characters

The plugin now reads a line break the way PostCSS and Stylelint do: a line feed, alone or behind the carriage return of a Windows pair. A bare carriage return and a form feed are plain whitespace, so a file broken with either is one line to every rule about breaks, empty lines and multi-line lists, and no rule reports a position your editor cannot show. The linebreaks rule still tells \n from \r\n.

Passing over @charset

The at-rule-name-case, at-rule-name-space-after, at-rule-name-newline-after, at-rule-semicolon-space-before and string-quotes rules no longer warn about a @charset or write into it, in any spelling: the encoding declaration is a byte sequence the browser reads before parsing rather than an at-rule, and every other spelling of it is ignored. Stylelint's at-charset-rule-no-invalid rule judges the spelling instead, so a CSS file holding a @charset now gets one warning asking you to enable that rule where your configuration leaves it off. The unicode-bom rule under "always" now warns about the option itself over a CSS file whose first node is a @charset, since the mark would keep the declaration from working; set "never" or leave the rule unset for such files.

Conflicting settings

The plugin now refuses a configuration holding two settings that conflict with each other, such as value-list-comma-newline-after: "always-multi-line" beside value-list-comma-space-after: "always": the run stops with a configuration error naming both settings and what to change (see #743). Where your configuration holds such a pair, change one of the two as the message says, or turn one of them off. The types of defineStylistic refuse such a pair in the editor.

Added

New rules

• The aspect-ratio-notation rule, which specifies how the value of aspect-ratio is written (see #18).
• The declaration-block-single-line-max-declarations rule, which limits the number of declarations within a single-line declaration block (see #639). Stylelint 18 removes the rule of its own, and this one takes the same option, so a configuration moves it by renaming it to @stylistic/declaration-block-single-line-max-declarations. It reads more than Stylelint's did — the single-line block of an at-rule as well (see #640) — and it is autofixable, which Stylelint's never was (see #641).
• The value-slash-newline-before and value-slash-newline-after rules, which require a newline or disallow whitespace on either side of the same solidus (see #622).
• The value-slash-space-before, value-slash-space-after, media-feature-slash-space-before and media-feature-slash-space-after rules, which require a single space or disallow whitespace on either side of the solidus of a value or of a media feature's ratio (see #548).

New options

... (truncated)

Commits

• 05bbb82 6.0.0
• 433f5c6 Upgrade stylelint to stable v18.0.0
• df33078 Fix monospace font size
• 800dce3 Replace the Geist font with Medeo
• c377fa3 Replace the syntax in the “Features” section on the main page with the recomm...
• aab9ab8 Bump postcss-less to v7
• f16e3fc Update dev dependencies
• e64ecb2 Add sponsorship URL
• 731ea11 Converge semicolon breaks with core comment spacing
• c3bf5e9 Count a closing brace at the end of a line in indentation
• Additional commits viewable in compare view