[feat] Sort key before spread

[remcohaszing]

Describe the problem

There are already rules to sort props.

• perfectionist/sort-jsx-props
• @stylistic/jsx/jsx-sort-props

These are stylistic rules. So they rightfully don’t sort props before or after prop spread syntax. However, when using the JSX automatic runtime, key is a special attribute in the JSX transform. See the Babel repl and TypeScript playground

If the key prop is before any spread props, it is passed as the key argument of the _jsx / _jsxs / _jsxDev function. But if the key prop is after spread props, The compiler uses createElement instead and passes key as a regular prop.

Describe the solution you'd like

It would be useful to have a rule that warns the user if the key prop appears after JSX spread syntax.

Alternatives considered

It could also be incorporated into @eslint-react/no-implicit-key.

Additional context

The key doesn’t have to be first, only before JSX spread syntax. Other rules can take care of sorting.

[Rel1cx]

This feature request has been accepted, I will add a jsx-key-before-spread rule.

[JounQin]

Hmm... Why not just port jsx-sort-props directly?

[remcohaszing]

There are already multiple rules to sort props. These correctly allow users to sort props before or after JSX spread syntax. This is important, because spread syntax changes the order in which the props override each other. The key prop is a special case. Its meaning changes depending on whether or not it appears after JSX spread syntax.

[JounQin]

Then why it must be implemented here instead of an option of perfectionist/sort-jsx-props nor @stylistic/jsx/jsx-sort-props?

[Rel1cx]

Then why it must be implemented here instead of an option of perfectionist/sort-jsx-props nor @stylistic/jsx/jsx-sort-props?

Because this is the only way to correctly set the severity of the two types of problems mentioned above under the ESLint plugin system, which allows setting jsx-key-before-spread to error, jsx-sort-props to warn, or setting jsx-key-before-spread to warn and override jsx-sort-props to info in the editor (via "eslint.rules.customizations"). And be able to correctly disable each of them in different contexts via eslint-disable comments.

[JounQin]

Because this is the only way to correctly set the severity of the two types of problems mentioned above under the ESLint plugin system

Why it/they should be considered two types of problems at the first place? There are many rules have different options, and different options share same severity, we don't provide different rules for each of them only for different severities?

[Rel1cx]

Because this is the only way to correctly set the severity of the two types of problems mentioned above under the ESLint plugin system

Why it/they should be considered two types of problems at the first place? There are many rules have different options, and different options share same severity, we don't provide different rules for each of them only for different severities?

This is exactly the bad practice, caused by a lack of understanding of the linter tool.