Add stylelint-disable commands support to autofix

[dan-gamble]

Describe the issue. Is it a bug or a feature request (new rule, new option, etc.)?

I have a file that has /* stylelint-disable */ /* stylelint-enable */ wrapped around it but when using --fix it tries to format this file and breaks it quite bad.

Which rule, if any, is this issue related to?

--fix

What CSS is needed to reproduce this issue?

Before
After

A few of the issues:

• Double ;; on L38
• No ; on L92 (I imagine this is where the ;; comes from

What stylelint configuration is needed to reproduce this issue?

Config

The config is pretty huge but i don't think it's the problem here

Which version of stylelint are you using?

7.11.0

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

CLI through lint-staged

[alexander-akait]

I think it is bug, should be respected by default.

[dan-gamble]

I think it also ignore ignoreFiles too fwiw.

[hudochenkov]

I know why stylelint-disable doesn't work with --fix. stylelint creates disabledRanges while processing style sheet. While linting, stylelint doesn't care about this ranges. They only matter, when stylelint generates report. It compares each violation and deletes violations within disabledRange.

I have no idea what to do with --fix and disabled ranges yet :(

[alexander-akait]

@hudochenkov maybe create util isStylelintDisable and check on this before fix in rule?

[hudochenkov]

I came up to another problem. Disabled ranges assigned before file linted/fixed. For rules which altered lines (change empty lines, add line endings), disabled ranges might be incorrect after few fixes. Even after fixes within one rule.

This problem affects every rule. Because if user has rule with fixing which changes lines, then every rule after this rule will have incorrect disabled ranges.

[jeddy3]

@hudochenkov Thanks for digging deeper. I suspect there are going to be some significant hurdles to overcome with this issue. As such, I suggest we push on with 8.0.0 and revisit this later. The autofix feature is marked as experimental and support for disable-ranges can be seen as a feature we'd like add, rather than a showstopping bug.

[hudochenkov]

I suspect there are going to be some significant hurdles to overcome with this issue. As such, I suggest we push on with 8.0.0 and revisit this later.

Agree. We should not close this issue, to not forget about this problem.

The autofix feature is marked as experimental and support for disable-ranges can be seen as a feature we'd like add, rather than a showstopping bug.

I think we should add a note somewhere about this caveat. And suggested strategy: if user is using stylelint --fix and stylelint-disable* comments, then stylelint should be run twice. First run there might be false violations (or ignored violations), because of shifted disable ranges. On second run all results would be correct. Also worth adding, that this strategy is for correct violation reports. --fix will fix everything regardless disabled ranges.

[alexander-akait]

@hudochenkov can we learn how it does eslint?

[hudochenkov]

@evilebottnawi of course we can. But I have a feeling that it won't help us, because of differences in architecture and approaches. Also I remember something from discussions, when we were discussing how to do autofixing. ESLint make multiple runs until everything is fixed and violations verified. And it also has some ranges for autofixing or something, that recalculated constantly. I might be mistaken about the last one.

[zkuzmic]

Any updates on this? Are you still looking for some help here?

[jeddy3]

Are you still looking for some help here?

@zkuzmic Yes, definitely. The issue has been labeled as "help wanted" for a while, but I don't think anyone has had time to pick it up as it's quite gnarly. Is it something you can help with?

[zkuzmic]

I'd be happy to look into it at least!

[SharakPL]

Since 13.2.0 stylelint no longer attempts to autofix sources which contain /* stylelint-disable */ comments, making the autofix feature safer to use.

However, the underlying issue still remains.

@stof's suggestion sounds viable:

instead of mutating the AST immediately, they would report with their fixer included, and the runner would then call that callback after checking the disabled ranges.

I believe the next step is a proof-of-concept (PoC) pull request showing this working with a rule or two. Once we are happy with the concept we can rally to migrate the 81 autofixable rules in stylelint to report with their fixer included.

If anyone has time, please consider contributing this PoC.

It works but it should also fix styles before /* stylelint-disable */ and after /* stylelint-enable */. For now it's just linting 😓

[stof]

It works but it should also fix styles before /* stylelint-disable */ and after /* stylelint-enable */. For now it's just linting

Respecting these comments is precisely what requires building the new suggested API to provides a fixer callback instead of running the fixing logic directly in the rule, so that the fixing logic could be run only when rules are not ignored.

[github-actions]

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

[Mouvedia]

instead of mutating the AST immediately, they would report with their fixer included, and the runner would then call that callback after checking the disabled ranges.

I believe the next step is a proof-of-concept (PoC) pull request showing this working with a rule or two. Once we are happy with the concept we can rally to migrate the 81 autofixable rules in stylelint to report with their fixer included.

If anyone has time, please consider contributing this PoC.

Iv refactored a rule to do just that.
@jeddy3 before I go further with the next step which is

and the runner would then call that callback after checking the disabled ranges

is this issue ready to implement?

[Mouvedia]

@ybiquitous is this issue ready to be implemented?

[ybiquitous]

Yes, I think creating a PoC has no problem. We could evaluate this feature by the PoC.

[Miofly]

how to resolve this problem

[Mouvedia]

Yes, I think creating a PoC has no problem. We could evaluate this feature by the PoC.

Sorry to be insistent, but I won't make the same mistake thrice.
Is this ready to implement?

[ybiquitous]

Yes, this is ready to implement. To clarify this problem, I just created a reproducible demo:

a {
	/* stylelint-disable */
	width: 0px;
	/* stylelint-enable */
	height: 0px;
/*           ^^ this "px" unit should be removed by autofix, but it isn't actually.
 */
}

// .stylelintrc.json
{
  "rules": {
    "length-zero-no-unit": true
  }
}