[Bug]: extension doesn't work since 1.0.0

[firestar300]

How did you encounter this bug?

Stylelint works as expected with my module bundler (Webpack) but the autofix on save and the Cmd Shift P > Stylelint: Fix all auto-fixable Problems command doesn't work anymore on VSCode.

Code Snippet

.slick-slide {
    border-top: none;
    height: inherit;

    >div {
        height: 100%;
    }
}

Log in Webpack :

ERROR in src/scss/vendor/_slick.scss
 1:1  ✖  Unknown rule function-calc-no-invalid          function-calc-no-invalid
 9:5  ✖  Expected "height" to come before "border-top"  order/properties-order

My stylelintrc config file is not located on the root workspace.
wp-content/themes/<THEME>/.stylelintrc

{
    "extends": [
        "stylelint-config-standard",
        "stylelint-config-recess-order"
    ],
    "plugins": [
        "stylelint-scss"
    ],
    "customSyntax": "postcss-scss",
    "rules": {
        "block-closing-brace-empty-line-before": null,
        "block-closing-brace-newline-after": null,
        "block-closing-brace-newline-before": null,
        "block-closing-brace-space-before": null,
        "block-opening-brace-newline-after": null,
        "block-opening-brace-space-after": null,
        "block-opening-brace-space-before": "always",
        "declaration-block-semicolon-newline-after": null,
        "declaration-block-semicolon-space-after": null,
        "declaration-block-semicolon-space-before": null,
        "declaration-block-trailing-semicolon": "always",
        "indentation": 4,
        "no-descending-specificity": null,
        "number-leading-zero": "never",
        "declaration-colon-newline-after": null,
        "max-line-length": 40000,
        "no-eol-whitespace": [
            true,
            {
                "ignore": [
                    "empty-lines"
                ]
            }
        ],
        "at-rule-empty-line-before": [
            "always",
            {
                "ignore": [
                    "inside-block",
                    "blockless-after-same-name-blockless",
                    "blockless-after-blockless"
                ]
            }
        ],
        "at-rule-no-unknown": [
            true,
            {
                "ignoreAtRules": [
                "extend",
                "at-root",
                "debug",
                "warn",
                "error",
                "if",
                "else",
                "for",
                "each",
                "while",
                "mixin",
                "include",
                "content",
                "return",
                "function",
                "use"
                ]
            }
        ],
        "string-quotes": "double"
    }
}

Extension Configuration

{
  "workbench.colorTheme": "One Dark Pro Flat",
  "editor.wordWrap": "on",
  "editor.fontSize": 12,
  "editor.tabSize": 4,
  "editor.quickSuggestions": {
    "other": true,
    "comments": true,
    "strings": true
  },
  "editor.snippetSuggestions": "top",
  "editor.renderWhitespace": "all",
  "editor.minimap.enabled": true,
  "editor.codeActionsOnSave": {
      "source.fixAll": true
  },
  "css.validate": false,
  "less.validate": false,
  "scss.validate": false,
  "[javascript]": {
    "editor.tabSize": 2,
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[scss]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[json]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[php]": {
    "editor.defaultFormatter": "wongjn.php-sniffer",
  },
  "phpcbf.enable": true,
  "phpcbf.executablePath": "./vendor/bin/phpcs",
  "phpcbf.documentFormattingProvider": true,
  "phpcbf.onsave": true,
  "phpcbf.standard": "./phpcs.xml.dist",
  "editor.largeFileOptimizations": false,
  "javascript.updateImportsOnFileMove.enabled": "always",
  "stylelint.enable": true,
  "stylelint.customSyntax": "postcss-scss",
  "stylelint.validate": [
    "css",
    "scss",
    "postcss"
  ]
}

Actual Behaviour

I cannot autofix with VSCode the stylelint issues.
Rollback to v0.87.6 fix the problem.

Expected Behaviour

I should be able to autofix stylelint issues with the latest version of the extension.

Stylelint Version

v14.0.1

vscode-stylelint Version

v1.0.2

Node.js Version

v14.16.1

Code of Conduct

• I agree to follow vscode-stylelint's Code of Conduct

[adalinesimonian]

Thanks for the bug report. To help figure out what's happening here, can you paste in the extension logs when VS Code is run with NODE_ENV set to development? You can start VS Code using NODE_ENV=development code on macOS/*nix or cmd /C "set NODE_ENV=development&&code" on Windows. Reproduce your issue, then select Stylelint in the Output window drop-down, and copy and paste the relevant logs here into the issue. Thanks!

[rpivet]

Seeing the same issue. Auto fix no longer functions. Here's my output after attempting to fire fix on save and through using the command palette:

[Info  - 4:58:10 PM] [language-server] Registering module | module: "auto-fix"
[Info  - 4:58:10 PM] [language-server] Module registered | module: "auto-fix"
[Info  - 4:58:10 PM] [language-server] Registering module | module: "code-action"
[Info  - 4:58:10 PM] [language-server] Module registered | module: "code-action"
[Info  - 4:58:10 PM] [language-server] Registering module | module: "completion"
[Info  - 4:58:10 PM] [language-server] Module registered | module: "completion"
[Info  - 4:58:10 PM] [language-server] Registering module | module: "formatter"
[Info  - 4:58:10 PM] [language-server] Module registered | module: "formatter"
[Info  - 4:58:10 PM] [language-server] Registering module | module: "old-stylelint-warning"
[Info  - 4:58:10 PM] [language-server] Module registered | module: "old-stylelint-warning"
[Info  - 4:58:10 PM] [language-server] Registering module | module: "validator"
[Info  - 4:58:10 PM] [language-server] Module registered | module: "validator"
[Info  - 4:58:10 PM] [language-server] Starting language server
[Info  - 4:58:10 PM] [language-server] Registering handlers
[Info  - 4:58:10 PM] [language-server] Handlers registered
[Info  - 4:58:10 PM] [language-server] Language server started

Node 12.22.3
vscode Stylelint extension 1.0.3
Stylelint 13.13.1

[adalinesimonian]

Here's my output after attempting to fire fix on save and through using the command palette:

I don't see any debug logs in your output — is VS Code started with NODE_ENV=development? Here's an example of the kind of logs you should see when VS Code's started correctly:

[firestar300]

Strangely, I cannot reproduce the bug anymore. I upgraded the extension to 1.0.3 and it works.

In version 1.0.3 I have a warning message :

Stylelint version 13.10.0 is no longer supported — you may encounter unexpected behavior. Please upgrade to version 14.0.0 or newer. See the migration guide for more information.

Locally in my project, I use stylelint v13.

[adalinesimonian]

Strangely, I cannot reproduce the bug anymore. I upgraded the extension to 1.0.3 and it works.

Glad to hear it! 1.0.3 has a bug fix for resolving Stylelint — perhaps that was the issue that you were running into.

In version 1.0.3 I have a warning message :

Stylelint version 13.10.0 is no longer supported — you may encounter unexpected behavior. Please upgrade to version 14.0.0 or newer. See the migration guide for more information.

Locally in my project, I use stylelint v13.

v1 of the extension was released together with Stylelint 14. While 13 may continue to work, it is no longer supported, so we highly recommend upgrading to Stylelint 14 — the extension migration guide and the Stylelint 14 migration guide explain what steps to take.

I'm closing this issue as the problem you originally ran into seems to be fixed.

@rpivet If you continue to experience bugged behaviour, please open a new issue, thanks!

[krzy789]

I'm still having issues with this, i installed stylelint 14.0.1, vscode-styleling 1.0.3, and i'm using emotionJS for styling, so my css properties are in *.styles.js files, but Vscode is not highlighting the wrong order of css properties.

I tried to add
"overrides": [ { "files": ["components/**/*.styles.js"], "customSyntax": "postcss-styled" } ]

to my .stylelintrc file, but without results(of course i also installed the postcss-styled package).

@adalinesimonian

[adalinesimonian]

I'm still having issues with this, i installed stylelint 14.0.1, vscode-styleling 1.0.3, and i'm using emotionJS for styling, so my css properties are in *.styles.js files, but Vscode is not highlighting the wrong order of css properties.

I tried to add "overrides": [ { "files": ["components/**/*.styles.js"], "customSyntax": "postcss-styled" } ]

to my .stylelintrc file, but without results(of course i also installed the postcss-styled package).

Does this work for you when using Stylelint from the command line? If not, go ahead and file a bug report.

[mbacalan]

Maybe I'm hijacking here but I'm having trouble seeing the reasoning behind introducing multiple breaking changes in v1.

VSCode is auto-updating extensions for most people and it took us a while to even discover that this extension was broken with our current configuration. And it seems that there are no errors, warnings or notifications. It's just silently failing.

We have a rather large project with fixed dependencies and upgrading Stylelint to v14 isn't as simple as it sounds. I feel like supporting only the latest release is a little too close to cutting edge. I also don't know the reasoning behind changes to default validators. Was the complexity caused by supporting them out of the box really worth the trade-off for requiring extra configuration to use widely used pre-processors?

I appreciate this extension getting updates as it seemed abandoned before but I hope some of these concerns can be understood too.

[adalinesimonian]

Maybe I'm hijacking here but I'm having trouble seeing the reasoning behind introducing multiple breaking changes in v1.

We have a rather large project with fixed dependencies and upgrading Stylelint to v14 isn't as simple as it sounds. I feel like supporting only the latest release is a little too close to cutting edge. I also don't know the reasoning behind changes to default validators. Was the complexity caused by supporting them out of the box really worth the trade-off for requiring extra configuration to use widely used pre-processors?

@mbacalan The difficulty for us is the old behaviour of the extension, where it would try linting any file type under the sun. We had a lot of issues with users where the extension was running Stylelint on file types it shouldn't have because of all the languages that were validated by default. Additionally, there was also the biggest breaking change in Stylelint 14, where auto-inferral of syntaxes was removed.

So, we made the decision to rip the bandaid off and only validate CSS by default, remove the syntax option, along with dropping support for 13 and prior due to the incompatibility in behaviour. The extension doesn't have any checks that tell it not to lint if it sees Stylelint 13 or prior, rather, we don't provide any support for those older versions of Stylelint. Therefore, it should, if the extension is configured to lint for a given file type, continue to work for 13 for a while, hopefully, enough time for people to migrate. You can find the discussion on this decision in #233. The issue for the v14 release is at stylelint/stylelint#5205

That said, I think that there is room for improvement. A few days ago, I was mulling over the idea of perhaps having some way to auto-detect if Stylelint was configured for a specific file — some way of knowing whether or not Stylelint had overrides configured for a given file, or some other similar check. While reverting to the old behaviour simply isn't an option due to the issues it caused, if there is a way for us to reduce friction using this extension without causing issues for other users or unreasonably adding to the maintenance burden, I am here for it.

VSCode is auto-updating extensions for most people and it took us a while to even discover that this extension was broken with our current configuration. And it seems that there are no errors, warnings or notifications. It's just silently failing.

The extension should be displaying errors in any workspace where it resolves a version of Stylelint less than 14:

However, because the extension only lints CSS by default, and the error is only displayed when a file that can be linted is opened, it wouldn't show in precisely the case you describe. Perhaps a better trigger for the warning would be when a workspace is opened; I think that'd be a good change we could make.

If you have any additional concerns, please open a new issue; that way the people subscribed to this issue, which was for a resolution bug, won't get email notifications for unrelated discussion. Thanks!