Add shorthand-property-sorting to recommended ESLint rules

[dddlr]

What is this change?

Add shorthand-property-sorting to recommended ESLint rules, meaning that it will be turned on by default for all codebases where @compiled/eslint-plugin set up correctly.

Why are we making this change?

After #1700 was merged in, Compiled will now sort shorthand properties to come before longhand properties at buiild-time and runtime. @zesmith2 made a lint rule to enforce that the order of the properties in the source code of Compiled usages matches this ordering. We've resolved all the eslint rule violations in jira and confluence (I think?), so we can just add this as a default recommended eslint rule to remove the need to configure it manually.

Some asks

Some requests from me before I go:

• If someone could extend shorthand-property-sorting so it handles the different forms of style composition, that would be great 🙏 @pancaspe87 has a link to the internal jira ticket for tracking this. @liamqma gave some examples in AFB-777 create eslint to enforce shorthand sorting #1714 (comment)

• If someone could quickly verify that the rule does indeed get applied in our products after the Compiled eslint plugin is version bumped, that would be great 🙏

---

PR checklist

Don't delete me!

I have...

• Updated or added applicable tests
• Updated the documentation in website/

[changeset-bot]

🦋 Changeset detected

Latest commit: 63d5d53

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@compiled/eslint-plugin	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[netlify]

✅ Deploy Preview for compiled-css-in-js canceled.

Name	Link
🔨 Latest commit	63d5d53
🔍 Latest deploy log	https://app.netlify.com/sites/compiled-css-in-js/deploys/671b272764fec30008615fc8

[AllySummers]

not sure how you like to handle this in compiled eslint plugin since it's still in 0.x.x (where basically anything goes), but just a note from a (very) opinionated eslint perspective.

this kind of change, if it were following the same semver policy as eslint core (and what many big eslint plugins use) and it wasn't in 0.x.x, it would be considered a breaking change. considering that, it may be appropriate to do at least a minor bump instead of patch?

feel free to ignore if you like to handle this in a different way for this plugin :)

from here: https://github.com/eslint/eslint?tab=readme-ov-file#semantic-versioning-policy

• Major release (likely to break your lint build)
  • eslint:recommended is updated and may result in new linting errors (e.g., rule additions, most rule option updates).

[AllySummers]

also i just realised, we should probably update the readme to reflect that this is now in the recommended config?

[dddlr]

also i just realised, we should probably update the readme to reflect that this is now in the recommended config?

ah you've already added it to the readme :p

[dddlr]

[dddlr]

not sure how you like to handle this in compiled eslint plugin since it's still in 0.x.x (where basically anything goes), but just a note from a (very) opinionated eslint perspective.

sure thing, will change to minor