Check @vue/composition-api Usages in no-ref-as-operand

[beeequeue]

Allows the rule to work with code imported from @vue/composition-api as well as vue.

With this the rule should probably be moved to essential instead of vue3-essential to make sure it's included for people using @vue/composition-api in Vue 2.

[ota-meshi]

Thank you for this PR!
I think it's good to support @vue/composition-api.

But I've never used @vue/composition-api, so I'm not sure if the same lint rule can be applied.

As far as I've checked the @vue/composition-api documentation now, I think that for the vue/no-ref-as-operand rule that change in this PR, customRef is extra tracking, but it's probably fine.

Can you see if other rules can support @vue/composition-api by making similar changes to this PR?

• vue/no-lifecycle-after-await
• vue/no-watch-after-await

---

We will not change the categories. Because using @vue/composition-api is optional and not required rule for all Vue 2.x users.

[ota-meshi]

If no other rule can be applied to @vue/composition-api then the reason why only this rule supports should be documented.

[beeequeue]

I added support for the other rules.

I do still believe it should be added to essential as it's in the same situation as in Vue 3 - using the composition API is optional there as well, but the rule is enabled either way since if the user isn't using it the rule will simply pass without complaints. It would be the same in Vue 2.

The rule is massively helpful in making sure you don't miss using .value - something very easy to do when starting to use composition - so it would make sense to include it for as many people as possible.

The only downside I can see is that it might take longer to run the linting, but I don't know how much that would increase by enabling one rule.

[ota-meshi]

Thank you for making other rule changes.

Did these rule changes work in your environment using @vue/composition-api?
I don't have time to check this.

---

The only downside I can see is that it might take longer to run the linting, but I don't know how much that would increase by enabling one rule.

I'm mainly concerned about this. The number of rules is small right now, but the problem will increase if more rules are added in the future.

[beeequeue]

It seems like @vue/composition-api doesn't support async setup functions, so I removed the rules relevant to that again. I don't know where I would add a note about it though.

Everything else seems to work as intended.

---

If I understand how ESLint's tracemaps work (based on how they're defined) wouldn't adding a rule where none of the relevant traces are hit not increase the performance significantly?

In this case it would only run the rule check if it would find a usage of one of the composition API functions - and otherwise it would just skip them.

[ota-meshi]

Thank you so much for checking the behavior of @vue/composition-api.

I don't think a note is needed because the other rules are "not need supports", not "cannot be applied".

If vue/no-ref-as-operand rule is included, it will not be skipped and will be processed. The processing consumed by vue/no-ref-as-operand rule is unnecessary for users who do not use @vue/composition-api. Therefore, we will not change the category. Users are free to enable the rules.
If you want to publish the ruleset for users who use @vue/composition-api, you can also publish the Shareable Configs.
https://eslint.org/docs/developer-guide/shareable-configs

[ota-meshi]

LGTM! Thank you!