New Rule: `no-duplicate-properties`

[przemyslaw-zan]

Rule details

Disallow duplicate properties within declaration blocks.

What type of rule is this?

Warns about a potential problem

Example code

a {
    /* Duplicate native property */
    color: pink;
    color: orange;

    /* Duplicate custom property */
    --custom-property: pink;
    --custom-property: orange;

    /* Not flagged with the option `allowFallbacks` */
    height: 100vh;
    height: 100dvh;
}

Prior Art

• declaration-block-no-duplicate-properties
• declaration-block-no-duplicate-custom-properties

Participation

• I am willing to submit a pull request to implement this rule.

AI acknowledgment

• I did not use AI to generate this issue report.
• (If the above is not checked) I have reviewed the AI-generated content before submitting.

Additional comments

• This proposal would mean merging two original stylelint rules into one, as they are nearly identical.
• Property comparison is case-insensitive for native properties but case-sensitive for custom ones - matching CSS spec.
• Equivalent of consecutive-duplicates-with-different-syntaxes option from the declaration-block-no-duplicate-properties rule should also be included: allowFallbacks.

[DMartens]

Generally I agree with the proposal, but I would keep "normal" and custom properties separate as it allowFallbacks makes sense for "normal" properties.
Further the stylelint rule allows ignoring consecutive declaration either by their value or unit and we should support this.
For example via allowFallbacks: boolean | 'value' | 'unit' (where true would allow both value and unit).
As this is a new rule, we first need team consensus before proceeding.

[przemyslaw-zan]

Original comment

Could it perhaps still make sense to keep this as a single rule, but simply point the allowFallbacks rule to impact normal properties only? Also, allowFallbacks refers specifically to unit type fallback, and makes no sense for value, so the name would have to change. I think we could make it a matrix:

• allowNativeDuplicates: boolean | 'value' | 'unit'
• allowCustomDuplicates: boolean | 'value' | 'unit'

WDYT?

---

I was wrong with some of my assumptions here. Fallbacks do not work for custom properties at all - their values are unparsed token streams, so no declaration is ever rejected at parse time and the last one always wins. That means allowFallbacks would apply to native properties only.

As for the modes: 'value' would allow consecutive duplicates for values differing in any way (e.g. position: -webkit-sticky; position: sticky), while 'unit' only those with differing syntaxes (e.g. height: 100vh; height: 100dvh, while still flagging color: blue; color: red). Since values that differ in unit differ as values too, 'unit' is effectively a subset of 'value' - and true ("allow both") ends up meaning the same as 'value'. So plain true can cover that case and the 'value' token can be dropped.

WDYT about settling on:

• a single rule
• custom property duplicates always reported
• allowFallbacks: boolean | 'unit' (native properties only)

[DMartens]

My proposed difference of value and unit meant that value only ignores if the declaration has a value without a unit and unit only if it has a unit (so there is no overlap).
I would still prefer separate rules because allowFallbacks as you noted does not apply to custom properties.

[przemyslaw-zan]

☝️ With unit we need to be careful to let differing units pass while same units should be flagged.

    /* Differing units, valid fallback. */
    prop: 100vh;
    prop: 100dvh;

    /* Same units, clearly a mistake. */
    prop: 100px;
    prop: 200px;