Issue with `at-rule-semicolon-space-before:never` when no semicolon in use

What steps are needed to reproduce the bug?

npm install postcss postcss-scss stylelint --save-dev

stylelint test.scss

// test.scss
.padding-bottom-15 { padding-bottom: 15px }

.element { @extend .padding-bottom-15 }

What Stylelint configuration is needed to reproduce the bug?

module.exports = {
    customSyntax: 'postcss-scss',
    rules: {
        'at-rule-semicolon-space-before': 'never',
    },
};

How did you run Stylelint?

CLI with stylelint test.scss

Which version of Stylelint are you using?

14.12.1

What did you expect to happen?

There should be no output from Stylelint as no semicolons are in use.

What actually happened?

The following problem was reported:

test.scss
 3:39  ✖  Unexpected whitespace before ";"  at-rule-semicolon-space-before

I have found that I can stop the error by adding a semicolon but this shouldn’t be necessary.

// test.scss
.padding-bottom-15 { padding-bottom: 15px }

-.element { @extend .padding-bottom-15 }
+.element { @extend .padding-bottom-15; }

Does the bug relate to non-standard syntax?

Yes, it could be related to the use of @extend (SCSS)

Proposal to fix the bug

Unfamiliar with the code but happy to take a look if nobody else can spot what the issue might be

[CAYdenberg]

I don’t remember writing this code, but it seems pretty clear this is a bug, no? (even if this rule isn’t something Stylelint should still have, this is clearly wrong). I can take a look later today.

[jeddy3]

No problem - are there example instructions/config of using Prettier alongside Stylelint?

Yep, in the getting started guide. There’s a section for setting up Stylelint for SCSS using the community SCSS standard config and the Prettier SCSS one.

(Going forward, the Prettier configs won’t be needed as we’ll remove the stylistic rules from the standard configs. Although, this could be some while down the line.)

Can Prettier omit certain output?

It’s an opinionated pretty printer, e.g. it always uses multi-line blocks and semicolons.

I don’t remember writing this code, but it seems pretty clear this is a bug, no?

Yep, it’s a bug but we’ve frozen the stylistic rules as we’re going to remove them in the next major release. We’re avoiding investing time in fixing, reviewing and releasing changes to them.

@CAYdenberg Thanks for offering to look into it. We understand that some people would prefer to continue using Stylelint for stylistic rules, and we’re hoping they will create a 3rd party plugin pack to offer this (where bugs like this one can be fixed). The built-in rules will then only be for avoiding errors and enforcing non-stylistic conventions, i.e. a linter rather than a formatter as well.