Incorrect TS issues being reported after upgrade to 2.2.6

[richmason]

Vue - Official extension or vue-tsc version

2.2.6

VSCode version

1.97.2

Vue version

3.5.13

TypeScript version

5.7.3

System Info

package.json dependencies

Steps to reproduce

Create a SFC with a v-model that accepts different types, such as:

const model = defineModel<string | number>({
    required: true,
});

Then use the component:

const testValue = ref("Hello, World")

<MyComponent v-model="testValue" />

What is expected?

Given the following is valid TS:

let test:string | number = "test"
test = 8;

There should be no TypeScript errors.

What is actually happening?

The following error is being displayed in VSCode:

Type 'string | number' is not assignable to type 'string'.
  Type 'number' is not assignable to type 'string'. ts-plugin(2322)

Link to minimal reproduction

https://github.com/richmason/vue-ts-issue

Any additional comments?

This was not an issue in version 2.2.4

[Yizack]

The issue was introduced in

• fix(language-core): validate v-model variable against model type #5214

I also had a reproduction for this

https://stackblitz.com/edit/vitejs-vite-zgqorhob?file=src%2Fcomponents%2Fcomp.vue

[KazariEX]

This is expected behavior, since v-model is two way bindings. It requires that the variable passed in is strictly consistent with the type of model value.

[wiidede]

This is expected behavior, since v-model is two way bindings. It requires that the variable passed in is strictly consistent with the type of model value.

But, why? Parent component model value is string, why could the update event become string | number only because the child component supports number? Shouldn't it be consistent with the model value's type string?

This change seems causes a huge amount of v-model type errors.

[Yizack]

This is expected behavior, since v-model is two way bindings. It requires that the variable passed in is strictly consistent with the type of model value.

Though there are cases that for reusability we'd like to accept two types or more, this restriction is messing with so many uses

[KazariEX]

https://vuejs.org/guide/components/v-model.html#under-the-hood

https://www.typescriptlang.org/play/?#code/JYWwDg9gTgLgBAbzgEwKYDNgDtUGELgQ5YwA0cAFnAL5zpQFwBEAbgK6pMDcAUDwMZEAzvHzg4AXhQZseApGIwAFAh4BIAPoaYATzCoACgzBCAXIloBDIYnVqQENABsAapacdzIqNgDmcAB84LDYQACNUKF41alJ1LV19AFEQYBgzCzhrWzU1JjYwZEsYVFMHZzcPTnMAbRZ3TzhvP0Dg0IioAF1o6h5qAEpeHidUeHQICABCLxgfLF8hiiUxMHJVe0dUVwbSugm4vKIAVULi0vKtyo4mcyV6qv7JAD49iEk4e44+waA

[wiidede]

@KazariEX
I still think defineModel's behavior is like

<script setup lang="ts" generic="T extends string | number">
const props = defineProps<{
  modelValue: T
}>()
const emit = defineEmits<{
  'update:modelValue': [value: T]
}>()
</script>

rather than

<script setup lang="ts">
const props = defineProps<{
  modelValue: string | number
}>()
const emit = defineEmits<{
  'update:modelValue': [value: string | number]
}>()
</script>

[KazariEX]

So why don't you write like:

<script setup lang="ts" generic="T extends string | number">
defineModel<T>();
</script>

?

[wiidede]

So why don't you write like:

<script setup lang="ts" generic="T extends string | number"> defineModel(); </script>

?

Because many components(also from library) write defineModel<string | number> and v2.2.6 break it.

[KazariEX]

You can report those issues to the upstream libraries and pin the version at v2.2.4. Anyway, the current behavior is inevitably brought through the implementation of two way bindings of types.

[KazariEX]

It seems difficult to implement complete type checking in these upstream component libraries😅We should make this feature default to false and opt-in.

[pzgz]

it would be nice if there can be an option to not opt-in this feature, there're just too many errors after upgraded to 2.2.6, considering this is just a minor version upgrade, and the changes brought are breaking.

Can understand the requirement of type checking on two way bindings. But it's pretty tricky actually. Most of time, for example, there's a component has v-model supporting string | number, let's say it's a radio, and then we assigned it to a ref which is a number, we can do so because all the radio options are number. But I don't think compiler should have the obligation to check all this kind of situation. Maybe developers themself should take the responsibility, but for now, if we don't cast in v-model binding, it just stop from compiling.

[KazariEX]

In the case you mentioned generics are the most suitable.

[KazariEX]

Please update to v2.2.8.