feat(biome_css_analyze): add rule useSortedProperties

[simon-paris]

Summary

Related: #3 (comment), #3167

This implements CSS declaration and rule sorting from the stylelint-order plugin. It sorts properties (and nested rules) in a consistent order, e.g:

  ! Properties should be sorted: display should be before color.
  
  > 1 │ .class { color: red; display: block; }
       │       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  
  i Safe fix: Sort these properties
  
    1    │ - .class·{·color:·red;·display:·block;·}
       1 │ + .class·{·display:·block;·color:·red;·}

The property order comes from the most popular preset config: stylelint-config-recess-order.

This is the equivalent stylelint config:

{
	extends: ['stylelint-config-recess-order'],
	rules: {
		order/order: [
		        "custom-properties",
		        "declarations",
		        "rules",
		        "at-rules"
	        ]
	},
}

The sort order is this: (ties stay in the same relative order)

1. Node kind:
   a. Custom properties
   b. The "composes" property
   c. Properties
   e. Nested rules and at-rules
   f. Other
2. Property name:
   a. By the order defined in PROPERTY_ORDER
3. Vendor prefix:
   a. By the order defined in VENDOR_PREFIXES
   b. Properties with no vendor prefix

Some possible issues:

• This is the only CSS rule that has a quickfix. I'm not sure if quickfixing CSS is stable. Seems to work though.
• stylelint-config-recess-order has an open PR that changes the order a little bit. It'd be best to wait for that to merge and sync the ordering before promoting this rule.
• stylelint-config-recess-order doesn't list every property. There are 230 (rarely used) properties that have no defined order. I'd rather not unilaterally decide where they go so I've left them out for now. This rule silences itself if any property exists that isn't in the list. The stylelint version doesn't raise errors for unknown properties but applying any autofix will move them to the end.
• I've had to duplicate some logic from the noShorthandPropertyOverrides rule because this rule would apply incorrect quickfixes in that case. I've made this rule silence itself if that rule would have fired. Not sure if that's the right approach. The stylelint plugin doesn't do this and applies the fix even when its unsafe.
• I've used LazyLock<HashMap> to implement some lookup tables for this rule. Not sure if that's a good method, I'm new to rust.

Test Plan

Unit tests are included.

[codspeed-hq]

CodSpeed Performance Report

Merging #4063 will degrade performances by 19.89%

_{Comparing simon-paris:feat/use-sorted-properties (8bbed82) with main (e3e37ab)}

Summary

❌ 3 regressions
✅ 94 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	main	simon-paris:feat/use-sorted-properties	Change
❌	css_analyzer[bulma_5641719244145477318.css]	621.4 ms	718 ms	-13.45%
❌	css_analyzer[foundation_11602414662825430680.css]	149.6 ms	186.7 ms	-19.89%
❌	css_analyzer[tachyons_11778168428173736564.css]	122 ms	142.6 ms	-14.42%

[ematipico]

Thank you @simon-paris for the contribution. I will look into this rule this week. As a very early feedback, this rule should be made an assist (apologies for the lack of documentation, I will try to fix that ASAP).

Here's an example of assist: https://github.com/biomejs/biome/blob/main/crates/biome_json_analyze/src/assists/source/use_sorted_keys.rs

[EvHaus]

I know sorting alphabetically may have issues (example) but I'd really appreciate having an option for it. For me it's much more useful than the "recess-order" configuration. Would it be difficult to add support for it?

[ematipico]

What's a "recess-order"?

[EvHaus]

The grouped order that stylelint-config-recess-order uses by default, and the one this PR was based on.

[jeddy3]

I'd appreciate having an option, too.

It looks like stylelint-config-recess-order was chosen because it's the most popular shared config. However, the Stylelint order plugin has a dedicated rule for alphabetically sorting, and that may not have been taken into account. It's difficult to compare its popularity with those of the shared configs, as they have their own npm download stats.

The dedicated rule is used in 2.1k public configs, so a lot of people prefer to sort alphabetically. Probably because there are 600+ properties, with more added all the time, so it's hard to maintain meaningful categories for all these.