Fix autofix introducing new violations

[wKich]

Clearly describe the bug

Some rule ignore indentation rule and as result after auto fix I receive error about indentation and should call auto fix second time to fix my files. If I try to use prettier-stylelint than I get unfixable indentation error, because stylelint is called once.

Which rule, if any, is the bug related to?

declaration-colon-newline-after or maybe value-list-comma-newline-after. I think this happen because of PR #3588

What LESS is needed to reproduce the bug?

:local {
  .root {
    &:active .box {
      background: #e1e1e1;
      box-shadow: 0 -1px 0 0 rgba(0, 0, 0, 0.1), 0 0 0 1px rgba(0, 0, 0, 0.2),
        inset 0 1px 2px 0 rgba(0, 0, 0, 0.1);
    }
  }
}

What stylelint configuration is needed to reproduce the bug?

extends:
  - stylelint-config-standard
  - stylelint-config-css-modules

Which version of stylelint are you using?

    "stylelint": "^9.9.0",
    "stylelint-config-css-modules": "^1.3.0",
    "stylelint-config-standard": "^18.2.0",

How are you running stylelint: CLI, PostCSS plugin, Node API?

CLI with stylelint "./**/*.less" --fix

Does the bug relate to non-standard syntax (e.g. SCSS, Less etc.)?

I think No.

What did you expect to happen?

Correctly formatted file:

:local {
  .root {
    &:active .box {
      background: #e1e1e1;
      box-shadow:
        0 -1px 0 0 rgba(0, 0, 0, 0.1),
        0 0 0 1px rgba(0, 0, 0, 0.2),
        inset 0 1px 2px 0 rgba(0, 0, 0, 0.1);
    }
  }
}

What actually happened (e.g. what warnings or errors did you get)?

After first auto fix I receive:

:local {
  .root {
    &:active .box {
      background: #e1e1e1;
      box-shadow:
        0 -1px 0 0 rgba(0, 0, 0, 0.1),
 0 0 0 1px rgba(0, 0, 0, 0.2),        /* <--- Here line with indentation error */
        inset 0 1px 2px 0 rgba(0, 0, 0, 0.1);
    }
  }
}

[jeddy3]

@wKich Thanks for the clear report and for using the template.

I receive error about indentation and should call auto fix second time to fix my files

This is, unfortunately, a known limitation. We don't yet have a robust way to avoid introducing violations for rules that have already been run.

As a workaround, you can see if adding the indentation rule as the last entry in your configuration object helps? e.g.

extends:
  - stylelint-config-standard
  - stylelint-config-css-modules
rules:
  - indentation
    - 2 

There is some further discussion on this limitation, but help is needed to resolve it in a robust way.

I'll keep this issue open, but rename it so that we can draw attention to this limitation and hopefully galvantise support to fix it.

[golopot]

I think stylelint cli should run fixer multiple times, like what eslint does.

After applying fixes, ESLint will run all of the enabled rules again on the fixed code, potentially applying more fixes. This process will repeat up to 10 times, or until no more fixable problems are found. Afterwards, any remaining problems will be reported as usual.

[jeddy3]

I think stylelint cli should run fixer multiple times, like what eslint does.

SGTM. Feel free to contribute a proof of concept PR.

[Mouvedia]

Is this about rolling back to the state before the last fix—and skip that error—if a new error has been detected or is it about introducing a new flag (e.g. --maximum-run-per-file)?
These two features are completely different.

PRO of the former: you only have to run it a second time at the end (to rollback specific hunk of code)
CONS of the former:

• you have to fix the skipped errors manually
• the rollback implementation is pretty complicated

CONS of the latter:

• run speed will greatly diminish (running it again to verify no errors were introduced for each file is overkill)
• risk of infinite loops

[jeddy3]

Is this about rolling back to the state before the last fix—and skip that error—if a new error has been detected or is it about introducing a new flag (e.g. --maximum-run-per-file)?

The latter. Although, it's less of an issue these days now that we're moving away from stylistic rules as the rules that avoid errors and enforce convention tend not to introduce new violations.

[Mouvedia]

the rules that avoid errors and enforce convention tend not to introduce new violations

• indentation
  • value-list-comma-newline-after
  • function-comma-newline-after
  • declaration-colon-newline-after
  • declaration-block-semicolon-newline-after
  • block-opening-brace-newline-after
  • block-closing-brace-newline-after
  • selector-list-comma-newline-after
  • media-query-list-comma-newline-after
  • at-rule-name-newline-after
  • at-rule-semicolon-newline-after

Are all the *-newline-after rules affected?
Can we share a common util for the handling of indentation?
related discussion: #2532 (comment)
related question: stylelint/stylelint-config-standard@090055e#r81509647

Is selector-not-notation the only rule that may have an impact on no-descending-specificity?
ref: #6236
Are there rules that affect selector-max-specificity?
ref 2f24d8b

I am asking all of this for the projected tests.

[github-actions]

This issue is older than one month. Please ask before opening a pull request, as it may no longer be relevant.