Plugin for sorting style keys

[steida]

Tailwind has such a plugin: https://tailwindcss.com/blog/automatic-class-sorting-with-prettier.

Is it a good idea to have something similar for StyleX? 🤔

[nmn]

This is a good idea and something that is planned but we can't prioritise. Thanks for creating the issue and hopefully someone can take this on.

The easiest solution is a fork of the sort-keys ESLint plugin that put the @ and : at the end of the list. The actual specificity of at-rules and pseudo-classes can be used to sort in the actual order within a property too.

This is a good contribution opportunity for something meaty.

[nedjulius]

hey, I will take a stab at this. seems interesting

[nedjulius]

hey, just wanted to inform interested parties that I am still looking into this issue. just didn't have much time to invest lately.

[nmn]

@nedjulius If someone starts working on this, we'll comment here to let you know!

[necolas]

Is this about sorting the namespace keys, or the property keys? Is it safe to reorder property keys for every resolution option available in the compiler?

[nmn]

@necolas This is about property keys. And from what I've seen it's always safe to sort property keys as long as standard CSS properties are used. I'll verify there are no exceptions where a shorthand comes after a long hand alphabetically.

If needed we should ensure the shorthands always come first in the sorted list, which will work for all resolution options.

[nedjulius]

alright, I started working on this issue. before I make any further strides, I would like you to evaluate some of the assumptions that I am currently making:

• we are only concerned about sorting the style property keys and pseudo-classes (:hover, @media etc.)
• because of the assumption above, we only care about evaluating the sorting within class names inside stylex.create, stylex.keyframes, create and keyframes; we do not care about sorting the class names
• we allow ascending and descending order, with the former being alphabetic, then :.. pseudo classes, then @... pseudo classes and the latter reverse

[nmn]

we allow ascending and descending order

We will only allow ascending order. Essentially all style keys will be sorted alphabetically, then @ at-rules then : pseudo classes and :: pseudo elements will be the very last. The same rules will apply to nested objects.

For the order within at-rules, pseudo classes and pseudo-elements, look at this file:

https://github.com/facebook/stylex/blob/main/packages/shared/src/utils/property-priorities.js#L0-L1

[nedjulius]

what would be the sorting for spread styles? say we have something like this:

const reusableStyles = { display: 'flex' }
const styles = stylex.create({
  foo: {
    position: 'relative',
    ...reusableStyles,
  }
});

is this even allowed? I tried compiling such example and it worked.

[nmn]

@nedjulius When the object is defined locally in the same file, that is allowed. You can also use stylex.include to spread styles from another file that have already been compiled using stylex.create.

The ESLint plugin should leave the spread in place and sort the keys and before and after as separate groups.

[zaydek]

hey, just wanted to inform interested parties that I am still looking into this issue. just didn't have much time to invest lately.

@nmn Just to confirm -- stylex.include is supported just not documented, right?

Also if it helps @nedjulius with prior art, I created and closed this issue in favor of this one. Will post the relevant text here:

One the killer user cases of traditional CSS is that you could use Stylelint and write a configuration file that describes the idealized order of properties. This is then enforced via VS Code plugin that draws underline squigglies when any of the properties are out of the idealized order, with the optionality to suppress ordering complaints if there's a good reason, e.g. // stylelint-disable or something like that. Unfortunately Stylelint didn't work quite well for SASS but I was able to run Stylelint on the .css output to the same effect.

This was a massive time saver because it meant there was no ambiguity about what ordering should look like, users can define their own idealized arrays in a configuration file, and VS Code was able pick up all of this. Sort of like Prettier for CSS property order.