feat(biome_js_analyze): add useSortedKeys assist rule

[r1tsuu]

Summary

Add a new assist rule - useSortedKeys which enforces ordering of a JS object properties.
This rule will consider spread/calculated keys e.g [k]: 1 as non-sortable.
Instead, whenever it encounters a non-sortable key, it will sort all the
previous sortable keys up until the nearest non-sortable key, if one exist.
This prevents breaking the override of certain keys using spread keys.

Source: https://perfectionist.dev/rules/sort-objects

// Base
// from
const obj = {
  b: 1,
  a: 1,
  ...g,
  ba: 2,
  ab: 1,
  set aab(v) {
    this._aab = v;
  },
  [getProp()]: 2,
  aba: 2,
  abc: 3,
  abb: 3,
  get aaa() {
    return "";
  },
};
// to
const obj = {
  a: 1,
  b: 1,
  ...g,
  set aab(v) {
    this._aab = v;
  },
  ab: 1,
  ba: 2,
  [getProp()]: 2,
  get aaa() {
    return "";
  },
  aba: 2,
  abb: 3,
  abc: 3,
};

How it is implemented

The run method of the rule queries JSObjectMemberList and collects all the members to Vec<Vec<ObjectMember>> state which is a list of groups, each group is separated by a spread or a computed key. Then, in the action we check if the current state is sorted (Ord was implemented for ObjectMember using natord for natural ordering) and if not - iterate through sorted - non sorted pairs (with zip) and replace the nodes.

The logic is very similar to the existing useSortedAttributes rule for JSX properties.

Test plan

Includes 2 snapshot tests - sorted and unsorted.

[dyc3]

As a general rule of thumb, we don't implement options for new rules on the first iteration to avoid unnecessary complexity. Lets leave these out for now.

[codspeed-hq]

CodSpeed Performance Report

Merging #5079 will not alter performance

_{Comparing r1tsuu:feat/useSortProperties (c3ebe18) with main (9280cba)}

Summary

✅ 94 untouched benchmarks

[ematipico]

Blocking because this PR should go against next and match the new contribution guidelines. The changeset is missing

[r1tsuu]

I updated the PR to be based on the next branch and added the changeset. Also renamed the rule as I noticed that useSortedProperties already exists for CSS.

[ematipico]

Also renamed the rule as I noticed that useSortedProperties already exists for CSS.

Biome linter is particular, and the same rule can be applied to multiple languages. If the intent of the rule is the same, we should implement the same rule for new languages.

Also, there's already a rule called useSortedKeys in the JSON language, which does exactly the same for this rule, hence I believe they should share the same name.

[r1tsuu]

Also renamed the rule as I noticed that useSortedProperties already exists for CSS.

Biome linter is particular, and the same rule can be applied to multiple languages. If the intent of the rule is the same, we should implement the same rule for new languages.

Also, there's already a rule called useSortedKeys in the JSON language, which does exactly the same for this rule, hence I believe they should share the same name.

It makes sense, I tried to rename to useSortedKeys and It causes some overlap for the codegen because they, although are for different languages share the same namespace for the config:

biome/packages/@biomejs/biome/configuration_schema.json

Lines 3903 to 3940 in a41878d

	"Source": {
	"description": "A list of rules that belong to this group",
	"type": "object",
	"properties": {
	"organizeImports": {
	"description": "Provides a whole-source code action to sort the imports in the file using import groups and natural ordering.",
	"anyOf": [
	{ "$ref": "#/definitions/RuleAssistConfiguration_for_Options" },
	{ "type": "null" }
	]
	},
	"recommended": {
	"description": "It enables the recommended rules for this group",
	"type": ["boolean", "null"]
	},
	"useSortedAttributes": {
	"description": "Enforce attribute sorting in JSX elements.",
	"anyOf": [
	{ "$ref": "#/definitions/RuleAssistConfiguration_for_Null" },
	{ "type": "null" }
	]
	},
	"useSortedKeys": {
	"description": "Sorts the keys of a JSON object in natural order",
	"anyOf": [
	{ "$ref": "#/definitions/RuleAssistConfiguration_for_Null" },
	{ "type": "null" }
	]
	},
	"useSortedProperties": {
	"description": "Enforce ordering of CSS properties and nested rules.",
	"anyOf": [
	{ "$ref": "#/definitions/RuleAssistConfiguration_for_Null" },
	{ "type": "null" }
	]
	}
	},
	"additionalProperties": false

, the same in crates/biome_configuration/src/analyzer/assist/actions.rs. The same for useSortedProperties, it already exists here

[dyc3]

That should be fine. Is the codegen throwing any errors for you? It works fine on my machine.

[r1tsuu]

The current commit is fine, I was about to rename that property from useSortedObjectProperties to useSortedKeys and it overlaps with the other property that has the same name in the source config namespace. Codegen doesn't throw any errors for that case, but then the current useSortedKeys and my useSortedKeys basically share the same description / config type, which probably isn't a desired behavior.

[dyc3]

We do this with other rules, like noDuplicateObjectKeys. Users are able have control over which language and files the rule applies to. So it's OK to have the rule names overlap.