feat(attributes-order): add slot attribute

[CyberAP]

First of all thanks for such a great eslint plugin for Vue! It helps my team a lot to have consistent code practices.
Secondly, I'd like to improve the tool a little bit because in our case it wasn't possible to migrate some of the codebase to support eslint without changing plugin's code.

Motivation

There's a rule attributes-order that is included in the recommended ruleset which has predefined attributes set. This set is great, but in some cases might be a bit limiting. In particular, there's no separate treatment for key, ref vs slot and v-slot right now (they are mutually controlled by the UNIQUE option) and I would like to improve that.

The reason for controlling them separately is that ref and key respond to the outer interface of the component, so I would like to have these attributes as high as possible. On the other side, slot and v-slot respond to the inner interface of the component by controlling it's ancestors placement within the component and passing data down the render tree. I would like to have that attribute as low as possible so it's closer to the actual elements it's controlling.

Basic example of the attribute order I would like to have:

<SlottedComponent
  ref="slottedComponent"
  :key="key"
  :data="data"
  v-slot="{ item }"
>
  <ItemComponent :item="item" />
</SlottedComponent>

With this change in place users will be able to place slots as close to the ancestors as possible without affecting ref and key order.

Implementation

This is not a breaking change. Users who don't want to control slot attribute position won't have to do so, it will inherit UNIQUE position by default. However if you do want to control it you can do it without breaking any existing rules.

I've covered this change with a few tests, also updated the docs (version number might need a change though).

[ota-meshi]

Thank you for this PR!
I agree that v-slot should be separated from UNIQUE.

However, I think it's complicated and confusing that the default position is used when the user does not specify the position.
But I also understand that to you used default position to avoid a breaking change.

Let me consider it's.

[CyberAP]

@ota-meshi, thanks for the response! What do you think about the following update release strategy?

• For the next minor\patch version release this as-is, even though it might be confusing that SLOT inherits UNIQUE position by default. It will not break current code but will be future-compatible.
• For the next major version remove that position inheritance and always treat SLOT position separately from UNIQUE. If SLOT is not defined it will not be considered as a part of a UNIQUE option. This will be a breaking change, but for a major version that might be ok.