Disable autofix for `declaration-block-no-redundant-longhand-properties`

[ybiquitous]

What is the problem you're trying to solve?

We often find autofix bugs for declaration-block-no-redundant-longhand-properties

• Fix declaration-block-no-redundant-longhand-properties autofix for border stylelint#7609
• declaration-block-no-redundant-longhand-properties is not forwards compatible stylelint#7630
• declaration-block-no-redundant-longhand-properties needs to be value type aware stylelint#7631
• Fix declaration-block-no-redundant-longhand-properties and declaration-block-no-shorthand-property-overrides false negatives for transition-behavior stylelint#7917
• Fix declaration-block-no-redundant-longhand-properties autofix for grid-area property stylelint#7933

Currently, implementing autofix for new properties in this rule is challenging.

What solution would you like to see?

How about disabling autofix for this rule?

stylelint-config-standard/index.js

Line 55 in d319b67

'declaration-block-no-redundant-longhand-properties': true,

E.g.

'declaration-block-no-redundant-longhand-properties': [true, {disableFix: true}],

[Mouvedia]

How about disabling autofix for this rule?

I would say we should state what we will have to achieve to re-enable the autofix before disabling it.
Here's my take, it should handle:

• partial fixes (i.e. not all longhands are needed for the fix to happen)
• very common properties (e.g. Fix declaration-block-no-redundant-longhand-properties autofix for border stylelint#7609)
• reordering of properties while fixing (in correlation with the ignoreLonghands option)

stylelint/stylelint#7631 is a nice long term goal but it shouldn't be necessary to turn off disableFix.
If we are agreeing on a list, it should also be part of the commit message.

[ybiquitous]

@Mouvedia Thanks for the info. Considering conditions to re-enable autofix sounds reasonable. 👍🏼

@romainmenke Can you please hear your thoughts if you have any?

[romainmenke]

Can we iterate on this?

I think it's fine if we make some structural improvements and then re-enable the autofix.
We can then evaluate how many and how often we receive bug reports and decide if we want to keep the autofix or disable it again while awaiting more improvements.

This list seems fine to me:

#332 (comment)

---

I would also suggest adding some tooling around logical props.

See how we use @webref/css to build a graph of constituent props for @mrhenry/stylelint-mrhenry-prop-order

@webref/css is scraped from the css draft specs.

We use it as a dev dependency in @mrhenry/stylelint-mrhenry-prop-order to inform us when new properties have been specced.

A similar approach could be used to get a signal here?

This could allow us to be more accurate and more up to date with the mapping of shorthands and longhands.