Why can't Vue at least make its OWN types compilable / extendable?

[matthew-dean]

There have been a number of issues like this raised where the Vue compiler cannot interpret / extend TypeScript types if they are "too complex".

However, the problem is Vue's types itself, which are not extendable, and not supporting TypeScript inference in general.

For example, if you extend ButtonHTMLAttributes at all, the Vue compiler will fail. This is because Vue's own definition of ButtonHTMLAttributes is too complex and not usable as an extends. Were it to be simplified, my understanding is that the Vue compiler would succeed.

However, any issue that has been opened regarding this has not only been closed, but has been locked, indicating I assume, that Vue maintainers do not want it discussed? Does anyone know why this is?

[LinusBorg]

This topic is not a collection for various gripes you may have with Vue. hiding this as off-topic.

[LinusBorg]

This is not acceptable behavior and won't be rewarded with a response. Keep conversations constructive.

[LinusBorg]

However, the problem is Vue's types itself, which are not extendable, and not supporting TypeScript inference in general.

For example, if you extend ButtonHTMLAttributes at all, the Vue compiler will fail. This is because Vue's own definition of ButtonHTMLAttributes is too complex and not usable as an extends. Were it to be simplified, my understanding is that the Vue compiler would succeed.

The timeline is this:

1. we publish Vue 3.0 with these JSX types for ButtonAttributes etc.
2. we publish 3.2 with a very limited support of type-inferred props declarations
3. we publish 3.3 with an improved compiler covering more cases for type-inferred props declarations

Now we are here, where the (AST-based) compiler from 3.3 that analyses types for props declarations isn't (yet?) smart enough to support some of the more complex types we have been shipping since 3.0

So couldn't we "just" simplify the types? That can't be too hard, now, can it? Well, we have been shipping these types for a long time now. Some of our language tooling relies on these types. They are likely in use in many apps in other use cases than "extending them for props declarations". So it would prove pretty tricky to "just" simplify them while 1) still covering all the current applications they cover and 2) not break current usage in existing apps.

The more promising road is likely to further improve the compiler, but that is also a pretty complex task and we simply don't have the bandwidth for this currently.

Though we are happy to accept PRs that can solve the problem from either side - types simplification or compiler improvement.

However, any issue that has been opened regarding this has not only been closed, but has been locked, indicating I assume, that Vue maintainers do not want it discussed? Does anyone know why this is?

That's an interesting assumption. The issue that you specifically linked to was locked after it has been closed for months, and it was locked by a bot automatically by the following workflow, not by us as maintainers to censor discussion around this topic:

https://github.com/vuejs/core/blob/main/.github/workflows/lock-closed-issues.yml

Can you link me to any other related issues that have been closed and locked by maintainers while active discussion was going on?

[LinusBorg]

Also, there's another aspect to this that's important I think, specifically when we talk about these HTML attribute types:

interface Props extends ButtonHTMLAttributes {
  foo: string
}

defineProps<Props>()

If that worked as you are asking, this would add a runtime props definition containing around 100 (rough guess) non-minimizable strings to the bundle - for each component declaring props by extending these types:

{
  props: ['aria-checked', 'aria-whatever ', ........]
}

I don't think that's what most people really want. Thats a lot of dead weight accumulating in your bundle.

Vue already supports fallthrough attributes, so when we define a Button component, we usually don't even need access to these attributes as component props, we are fine with having these fall through on the nested <button>.

What most people want, is type hints for allowed attrs besides props.

This is foremost about better DX, so we can:

1. have typed attrs/$attrs in the code of our button component and
2. have type hints for the consumer of the component, so they get this experience:

We can get 2) kind of with this:

interface Props extends /* @vue-ignore */ ButtonHTMLAttributes {
  foo: string
}

const props = defineProps<Props>()

This will add the ButtonHTMLAttributes to the component props' type declaration, but will not to the generate runtime options. those will just be props: ['foo'].

The issue we have now though, is that the type for props inside of our buton component is wrong, because the object only has a single foo property, but the type lists all of these fallthrough attributes as well.

An ugly workaround would look like this:

interface Props extends /* @vue-ignore */ ButtonHTMLAttributes {
	foo: string
}
const _props = defineProps<Props>() // this makes sure consumers see the button attributes in autocomplete
const props = _props as Omit<typeof _props, keyof ButtonHTMLAttributes> // this cleans up the props type
const attrs = useAttrs() as ButtonHTMLAttributes // and this casts the attrs object to something matching the allowed fallthrough attributes

And I think a goal worth pursuing would be to find a way for that to happen automatically, i.e. have type-safe attrs that are combined with the external component props type declaration, see:

vuejs/rfcs#477

[andredewaard]

Is it possible with this approach to have better autocomplete for attributes? for example like this so we can do

interface Props extends /* @vue-ignore */ InputHTMLAttributes {
...
}

to get autocomplete on the autocomplete attribute