You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However both of these cause a warning in vetur if the prop is omitted when using TheComponent.
<TheComponent> misses props: foo
In the first example, this is because the syntax tree for the node after foo: is { "type": "AsExpression", "expression": { "type": "ObjectExpression", … }, while the lint here expects it to be exactly an ObjectExpression.
In the second example, we have a CallExpression.
Neither of these are required props, and the warning applying by default seems a bit aggressive. It leads to the entire template block being yellow underlined in many cases.
As an approximation, it might be more useful to match positively on { "type": "Identifier", "text": /^[A-Z]/ } instead of matching negatively on an object literal, which catches Object, Array, conventionally named custom classes, etc. It wouldn't match localVariable, optionalProp<Foo>(Object), { type: String } as T, and so on.
The text was updated successfully, but these errors were encountered:
Yeah, this all works fine for props that are required, like in your example. The issue is that the patterns for optional props with TypeScript are interpreted as required props by Vetur.
Info
Problem
This commit leaves no clear way to have a TypeScript type as the prop type while also having the property be optional.
Reproducible Case
Given the following...
You could define an optional prop as this:
Or this:
However both of these cause a warning in vetur if the prop is omitted when using TheComponent.
In the first example, this is because the syntax tree for the node after
foo:
is{ "type": "AsExpression", "expression": { "type": "ObjectExpression", … }
, while the lint here expects it to be exactly an ObjectExpression.In the second example, we have a
CallExpression
.Neither of these are required props, and the warning applying by default seems a bit aggressive. It leads to the entire template block being yellow underlined in many cases.
As an approximation, it might be more useful to match positively on
{ "type": "Identifier", "text": /^[A-Z]/ }
instead of matching negatively on an object literal, which catches Object, Array, conventionally named custom classes, etc. It wouldn't matchlocalVariable
,optionalProp<Foo>(Object)
,{ type: String } as T
, and so on.The text was updated successfully, but these errors were encountered: