stylelint: Deprecate declaration-block-properties-order in favour of more specific community plugins

I’ve released stylelint-order 0.2.0.

• Renamed property-groups-structure to declaration-block-property-groups-structure
• Added declaration-block-properties-specified-order rule

Do you thinks it’s ready for a public announcement?

Do you thinks it’s ready for a public announcement?

Lets:

• Update the release planning doc.
• Deprecate declaration-block-properties-order with a simple message within the changelog.
• Update the plugins list.

This will give people plenty of time to migrate to stylelint-order (and hopefully contribute any additional functionality they want to see) before we remove declaration-block-properties-order in stylelint@8.0.0

Once these three things are done, I think an announcement via a tweet would be nice 😃

@davidtheclark thank you! There is a good replacement — stylelint-order, because I’ve merged code from plugins above into new plugin 😃

Could property-groups-structure implement the same API it currently supports?

You suggest also to check order in property-groups-structure? Which means code for declaration-block-properties-specified-order also will be in property-groups-structure?

You might consider putting these plugins into a single plugin package or using the monorepo approach.

It’s an interesting idea. I can create stylelint-order plugin pack with these rules:

• declaration-block-order
• property-groups-structure
• declaration-block-properties-specified-order
• declaration-block-properties-alphabetical-order

I would like to make these plugins, since it’s kinda my thing to make order plugins for stylelint and PostCSS 😃

I think this illustrates how the rule is trying to do too much.

I agree with @jeddy3’s suggestion that we need to get serious about drawing some boundaries. I think the current should be altogether cut, and replaced with specific rules with clear boundaries. @jeddy3’s example could be broken down further into two distinct rules:

• declaration-block-properties-alphabetical-order
• declaration-block-properties-specified-order

I was thinking these rules could live within stylelint core — but then we run into compatibility problems. I do think this makes the most sense delegated to external plugins. People should simply pick the plugin that fits their idiosyncratic desire.

This leads me to think we should just cut the rule from stylelint altogether.

I think it would be cool if the end result was a setup was warnings for a custom order. But failures if properties are not written in a set order.

Can you please provide some more (minimal) examples of what you want to happen? e.g. “with the following config ..., the following CSS ... would produce the following ... warnings”.

Originally, I thought you were asking for an option that would allow for the flexible ordering of groups, but with a strict ordering within each group e.g.

{
  "rules": {
    "declaration-block-properties-order": [[
      {
        order: "strict",
        properties: [
          "position",
          "top",
          "right",
          "bottom",
          "left"
        ]
      },
      {
        order: "strict",
        properties: [
          "flex",
          "flex-direction",
          "flex-order",
          "flex-pack",
          "flex-align"
        ]
      }],
    { group: "flexible" }
  ]}
}

With such a config, both the following are valid:

a {
  position: absolute;
  top: 10px;
  flex: 1;
  flex-direction: row;
}

a {
  flex: 1;
  flex-direction: row;
  position: absolute;
  top: 10px;
}

As the order of each group is flexible, whereas the properties within each group aren’t.

Whereas, the following two examples would return one warning each, but on different lines:

a {
  position: absolute;
  top: 10px;
  flex-direction: row;
  flex: 1;
}

5:2 Expected "flex" to come before "flex-direction"

And:

a {
  flex-direction: row;
  flex: 1;
  position: absolute;
  top: 10px;
}

2:2 Expected "flex" to come before "flex-direction"

As the strict order within the “flex group” is being violated.

Is this what you’re asking for?. If not, I think some examples would help us better understand what you’re requesting.

Once we understand the request we can better judge whether it is inside or outside the scope of this rule.