Closed mauricekleine closed 1 year ago
@mskelton curious to hear your thoughts!
Btw I forgot to mention, but these changes are backwards compatible. Not adding any of the new options results in the same results as before - this is also covered in the tests
@mskelton makes sense, I'll add it to the other rules as well. I wasn't sure about setting the natural order as a default because it does change how people currently use the rule. If you're okay with that though, I'll set the default to true
.
I'm actually thinking, should it in that case just always be natural
order without having the ability to change the behaviour? So the only additional new config would be the caseSensitive
boolean for each rule:
{
"sort/object-properties": "error" // asc, natural order, case insensitive
}
or
{
"sort/object-properties": ["error", { "caseSensitive": true, }] // asc, natural order, case sensitive
}
I still think that natural
should be an option, just enabled by default. It's possible that in certain circumstances such as different languages, natural order might not work well, so I would at least like it an option, even if enabled by default.
@mskelton I implemented the case-sensitivity and natural order options for the other rules as well. Tests and docs are updated too. What do you think?
Awesome, thanks for polishing it @mskelton!
First of all, why is this repo not more hyped? 🤩
Eslint's
sort-keys
rule supports options for case sensitivity and natural order. I personally rely on the natural order a lot for sorting Tailwind properties in a classname object, for example:However, with the current default config for the object properties rule, the result would be the following:
Having the option to set whether or not the rule should use natural sorting, would be a great addition so that the above object would sort numeric string in a 'natural' way using
natural-compare
To keep it aligned with
sort-key
, I also added the option to choose betweenasc
anddesc
orders