Add attribute sorting rule

[adamjkb]

Motivation

Attributes on Svelte components and html can get unwieldy and hard to parse if there are too many. This is especially true when there is a lot of directives involved. One of the main thing I appreciate in eslint-plugin-react is their jsx-sort-props rule. It makes even complex components easy to read.

Proposed solution

Add sort-attributes rule to enforce a sort order of attributes. Alphabetical order would probably suffice for most cases however some sort of predefined "natural" order would be best. Here I'm thinking of the in: and out: directive. I think most would keep this two attributes logically together. jsx-sort-props has accumulated a fair amount of these, e.g.: on: event listeners last for Svelte.

A simple alphabetical ordering I usually maintain manually.

<Checkbox
  bind:this={checkbox}
  class="text-md"
  class:blue={isSelected}
  {completed}
  {id}
  in:fly
  on:change={handleChange}
  out:fade
  use:action
  {...$$props}/>

---

Appreciate any thought on this!

[ota-meshi]

Thank you for the rule proposal!
I think it makes sense to add a rule to sort the attributes.
However, I don't think the options in the jsx-sort-props rule are complicated and informative.

I think it's a good to add a rule that works by default without options, and then consider the options if other users request.
So we would like to consider the best attribute sort order for me and you. (For example, I want to put the id before the class. That's because the selector points are high.)
What do you think?

[ota-meshi]

I think it's better for us to sort as follows:

1. bind:this.
2. id attribute.
3. name attribute. (Only <slot>?)
4. --style-props
5. style attribute and style: directives. (It does not change the order within this category. Because the style can be broken.)
6. class attribute
7. class: directives. (Sort by name alphabetically within the category.)
8. bind: directives (other then bind:this), other attributes, and shorthands. (Sort by name alphabetically within the category.)
9. {...spread}
10. on: directives. (Sort by name alphabetically within the category.)

I'm wondering where the following directives should be.

• transition: directive.
• in: directive.
• out: directive.
• animate: directive.
• use: directives.

[adamjkb]

I think that's an interesting grouping so far. However I feel like grouping was a very half baked idea: I have a hard time justifying why would a tag like "aria-label" would be placed so far down. For me personally, 100% alphabetical sorting totally works for me.

But for the grouping my preference for the rest of the attributes would simply continue after your order:

11. use:
12. in:
13. out:
14. animate:

On the spreads position: We should be able to position anywhere, and they should act as a reset for the sorting. Because we need to retained the options to overwrite or protect any html attributes coming through in the restProps for example.

[hgiesel]

This topic was also discussed in the prettier-plugin-svelte repo.

There, they mentioned this example from the docs (last section), where the order of on: and bind: directives matter.

[ota-meshi]

@hgiesel Thanks for letting me know! That is important information.

[tivac]

I think a default ordering is fine, but I would likely not use this rule until I could fully define my preferred ordering schema using something like stylelint-order because the orders proposed here so far aren't what my team has been using.

[ota-meshi]

Can you share what rules you use to sort the attributes?

[tivac]

We manually maintain an ordering kinda like this, though we don't have any instances of some of these in our current codebase yet.

• id
• class
• class:
• value
• src
• data-*
• style
• style:
• on:
• use:
• animation:
• transition:
• in:
• out:
• bind:this
• bind:*
• {...spread} (this one is highly variable depending on the needs of the usage though, I wouldn't want to enforce its location necessarily)

[ota-meshi]

Thank you for sharing. Thanks to that I understand that we need options in the rules.
But I don't have any ideas for rule option specifications yet. I think we perhaps need to be able to specify the grouping of attributes, the order of the groups, and the order within the groups.
Do you have an idea for a rule option specification?

[tivac]

There's a few I've seen:

typescript-eslint/member-ordering
eslint-plugin-import/order
stylelint-order/order

For something like this I think I'm partial to simple string/regex matching in an array, maybe with a few special-cases for situations like the spread operator?

{
    "svelte/attribute-order" : [ "error", {
        "order" : [
            "id",
            "/class|class:.*/",
            "/value|src/",
            "/data-.*/",
            "/style|style:.*/",
            "on:.*",
            // ...
            "<spread>"
        ]
    }]
}

Dunno if that would make the rule too slow to be efficient, but it's at least relatively simple and feels flexible enough to handle all the cases I've seen in this thread?

If you want to enable sorting within all matching attributes you could also support a slightly more verbose version, potentially with more than one sort type supported? alphabetical, natural, or a custom sort function modeled after Array.prototype.sort(compareFn):

{
    "svelte/attribute-order" : [ "error", {
        "order" : [
            "id",
-           "/class|class:.*/",
+          "class",
+          { match : "/class:.*/", sort : "alphabetical" },
            "/value|src/",

The one downside to this approach is that the only grouping is via regex, which is maybe coarser than what you're looking for?

[ota-meshi]

Thank you for sharing your ideas.

I think it makes sense to use verbose version for option.

But I don't really like regex that don't use objects. Since regex indicate a group, I think user need to explicitly specify the order within the group.

{
    "svelte/attribute-order" : [ "error", {
        "order" : [
            "id",
            "/class:.*/", // <- Do you want to sort the attributes in the group or not?
            // ....
        ]
    }]
}

Also, I think it would be more convenient to be able to specify an array matcher. I think it's easier to read than using | in a regex.

{
    "svelte/attribute-order" : [ "error", {
        "order" : [
            "id",
-            "/class|class:.*/",
+            ["class", { "match": "/^class:.*/", "sort": "alphabetical" }],
-            "/value|src/",
+            ["value", "src"],
             // ....
        ]
    }]
}

The one downside to this approach is that the only grouping is via regex, which is maybe coarser than what you're looking for?

I think it makes sense to use regex because they are easy for many users to learn.
However, users may have to use slightly more complex regex to avoid confusion in the matching order.

For example, if user want bind:this to be placed after bind:* other than bind:this, the user must use negative lookahead.

I think it's acceptable, but what do you think?

[ota-meshi]

I noticed that there is no way to specify a simple attribute other than the one specified in the order.

For example, where do you want to specify a simple attribute that is not in the list below? I think that you probably can't express it well using regex.

• id
• class
• value
• src
• data-*
• style

[tivac]

Aside from ordering, what are you thinking of using the grouping info for? I think it's possible to do ordering without explicit grouping via arrays, and it seems like it'll add complexity to the options. As far as I know attributes are really only done inline with the starting tag or one attribute per line, so I'm not clear where grouping comes into play there.

I think it makes sense to use verbose version for option.

But I don't really like regex that don't use objects. Since regex indicate a group, I think user need to explicitly specify the order within the group.

The thought behind simple regexes was that there would be no sorting by default, you'd use the extended object syntax if you cared about sorting. For instance I don't have strong feelings about making sure that every data attribute appears in any particular order, so wouldn't necessarily want to have to pick one and have a bunch of my application code changed next time we ran a lint with --fix.

If you prefer only config objects it'll make for a bigger config but still accomplish the same thing assuming we can choose not to sort, so I'm fine either way.

Also, I think it would be more convenient to be able to specify an array matcher. I think it's easier to read than using | in a regex.

My concern about using something like a simple string array for matching instead of a regex is that you can't easily write one for "every single data- attribute" because that list would be huge. Same with all the style:* shorthands or bind;*. Array matching with wildcard support, or matching against the beginning of the attribute name would help maybe?