eslint-plugin-vue icon indicating copy to clipboard operation
eslint-plugin-vue copied to clipboard

Rule Proposal: Props must explicitly state requiredness

Open gwardwell opened this issue 7 years ago • 6 comments

Please describe what the rule should do: This rule should enforce including the required property, whether true or false, when defining a Vue Component prop as an object.

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

[X] Enforces code style [ ] 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:

Valid props definition:

export default {
    props: {
        myProp: {
            type: String,
            required: true,
        },
        myProp: {
            type: Boolean,
            required: false,
            default: true,
        },
    },
}

Invalid props definition:

export default {
    props: {
        myProp: {
            type: String,
        },
        myProp: {
            type: Boolean,
            default: true,
        },
    },
}

Why should this rule be included? Relying on the existence of a default property is not an indicator that a prop is required, nor is omitting the required property an indicator that the prop is not required. Explicitly stating whether or not a prop is required makes the component and how to use it easier to reason about.

gwardwell avatar Nov 03 '18 15:11 gwardwell

It is redundant to specify both required: false and default. Having a default already implies required: false.

chiawendt avatar May 10 '19 18:05 chiawendt

If required: false is implied by the presence of a default value, then shouldn’t that mean required: true is implied by the omission of a default value, therefore making required redundant in general?

I realize some may find this redundant, but being in my position where I manage a team of a reasonable size with a fairly large code base, I would rather have developers act with explicit intent, and would like my linting tools to enforce that as much as possible.

gwardwell avatar May 11 '19 00:05 gwardwell

Your reasoning is based on (A -> B) -> (!A -> !B), it is a logical fallacy called fallacy of the inverse.

chiawendt avatar May 11 '19 00:05 chiawendt

required: true only throws a warning in development mode. It is possible to successfully run an application in production with a required prop that is not assigned a value when the component is used. Therefore, I can see a situation where you may choose to provide a default value even for a required prop to prevent errors at runtime if the prop is inadvertently omitted. That may not the best way to solve it, but you could do it.

It is also possible to omit a default value for a prop that is not required, which would be the equivalent of assigning default: undefined. In an application where the developer chooses that pattern, they may choose to disable the ESLint rule that enforces defaults and instead enforce explicitly stating requiredness.

The fact that Vue allows properties to exist with or without a default value irrespective of requiredness and the fact that the ESLint rule requiring a default value can be disabled prevent the definition or omission of a default value from being a reliable indicator of requiredness.

gwardwell avatar May 11 '19 01:05 gwardwell

I like this idea a lot. It allows teams who wish to be consistent in this regard the opportunity to have tooling that supports it. It doesn't matter as much to me whether the "requiredness" could be inferred as it does that teams may want it that way. After all, code is written for humans to understand, not computers. So a rule option to support that seems like a good idea to me!

frostydustpile avatar May 13 '19 12:05 frostydustpile

Shameless plug (and a bit off-topic): This was one of the reasons for me to create the vue-ts-types module. Maybe it's helpful for someone.

FloEdelmann avatar Jun 21 '23 13:06 FloEdelmann