Extend vue/no-dupe-keys to support <script setup>

[nasvillanueva]

Please describe what the rule should do:
Similar to ESLint's no-shadow rule, it would be great to have something similar, like vue/no-prop-shadow where it would warn on local variable declaration that has the same name as a prop, which can lead to issues when referencing it in the template because props can be directly accessed from the template.

What category should the rule belong to?

[ ] Enforces code style (layout)
[x] Warns about a potential error (problem)
[ ] Suggests an alternate way of doing something (suggestion)
[ ] Other (please specify:)

Provide 2-3 code examples that this rule should warn about:

WARN

<script setup lang="ts">
defineProps<{
  msg: string;
}>()

const msg = "override props"; // WARN: there's already a prop named `msg`
</script>

<template>
  <div>{{ msg }}</div> <!-- vague reference. Is this from props or local variable? -->
</template>

WARN

<script lang="ts">
import { defineComponent, computed } from "vue";

export default defineComponent({
  props: {
    msg: String
  },
  setup: (props) => {
    const msg = computed(() => `Message: ${props.msg}`);
    
    return {
      msg, // WARN: there's already a prop named `msg`
    };
  }
})
</script>

<template>
    <div>{{ msg }}</div> <!-- vague reference. Is this from props or local variable? -->
</template>

Additional context

More context from the original issue:

• Rule Proposal: Prevent accessing props directly in the template #2095

[ItMaga]

WARN

<script lang="ts">
import { defineComponent, computed } from "vue";

export default defineComponent({
  props: {
    msg: String
  },
  setup: (props) => {
    const msg = computed(() => `Message: ${props.msg}`);
    
    return {
      msg, // WARN: there's already a prop named `msg`
    };
  }
})
</script>

<template>
    <div>{{ msg }}</div> <!-- vague reference. Is this from props or local variable? -->
</template>

@nasvillanueva In this part, the rule vue/no-dupe-keys resolve this case.

Maybe it would be better to extend vue/no-dupe-keys to support <script setup> instead of the new rule implementation?

[FloEdelmann]

I also think that vue/no-dupe-keys should be extended to support <script setup> instead of adding a new rule.

[zigomir]

I'm also seeing problems for reactive props destructuring https://blog.vuejs.org/posts/vue-3-3#reactive-props-destructure with [v9.14.0](https://github.com/vuejs/eslint-plugin-vue/releases/tag/v9.14.0)

[FloEdelmann]

Reactive props destructure is not supported in eslint-plugin-vue, since it is an experimental Vue feature.

[zigomir]

I see, thanks!

[Bernankez]

Hi, I have the same problem with this comment, but not using reactive props destructure, just like this:

const props = defineProps<{
    componentKey?: string
    fullData: UnfAble<HomeRootObject>
}>()

const { componentKey, fullData } = toRefs(props) // Duplicated key 'componentKey'.

Should this case be considered?

[4350pChris]

Hi, I have the same problem with this comment, but not using reactive props destructure, just like this:

const props = defineProps<{
    componentKey?: string
    fullData: UnfAble<HomeRootObject>
}>()

const { componentKey, fullData } = toRefs(props) // Duplicated key 'componentKey'.

Should this case be considered?

Same. Imho this is legit usage of duplicate keys and should not be considered for this rule. I had to deactivate this particular rule for now, as my whole project uses toRefs without reassigning to different names, causing hundreds of linting errors.

[FloEdelmann]

Indeed, this seems like a bug. A fix is already being worked on by @ota-meshi in #2189.