Rule Proposal: vue/no-undef

[mysticatea]

Please describe what the rule should do:

no-undef should report a use of undefined variables in templates.
Undefined variables are variables which satisfy all of the following conditions:

• It's not the allowed global variables.
• It's not the Vue.js instance members (e.g. $data, $props, ...).
• It's not $event if it's in v-on directive.
• It's not defined by both v-for directive and scope attributes.
• The properties (defined by data, computed, methods, ...) of the custom component don't include it.
  • I guess this has limitations in static analytics 🤔 .
• It's not allowed by rule's option.
• Directive comments like <!-- vue members: foo, bar ,baz --> does not include it.

This would be helpful to catch TypeErrors or typo.

Options

{
    "vue/no-undef": ["error", {
        "knownMembers": ["foo", "bar", "baz"]
    }]
}

• knownMembers (string[]) ... A list of known properties. Use for properties which are defined by Vue.js plugins.

What category of rule is this? (place an "X" next to just one item)

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

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

<template>
    <!-- vue members: aaa -->
    <div>
        <div>{{ aaa + bbb + ccc }}</div>
        <div>{{ i }}</div><!-- "i" is not defined in this scope. -->
        <ol v-for="i in 5">
            <li :key="i">{{ bbb + k}}</li> <!-- "k" is not defined in this scope. -->
        </ol>
    </div>
</template>
<script>
import other from "./other"
export default {
    props: ["bbb"],
    data() {
        return {
            ccc: 1,
            ...other  // hard to know properties in `other`.
                      // You can declare it by `<!-- vue members: aaa -->`-like comments.
        }
    }
}
</script>

[armano2]

@mysticatea We should take into account extends due to complexity.

[michalsnik]

I don't think we'll be able to catch all of the possible cases here. Especially the one with extends where theoretically we'd have to check another component too, and then maybe another and so on and so on. If you already have an idea of how to best implement it @mysticatea please share your thoughts here too :)

[michalsnik]

@mysticatea I'm going to close this proposition, as I believe it's almost not possible to implement and even if it is - because of the number of different criteria that should be satisfied it will most likely cause some false positives and may cause more harm than good. If you don't agree and have an idea of how to best tackle this, please reopen this issue and share your thoughts :)