fix(types): props type is incompatible with setup returned type

[rudyxu1102]

Fixes #5885

Problem

// never
type Foo = {
    size:  'small' | 'big'
} & {
    size: number
}

[netlify]

❌ Deploy Preview for vuejs-coverage failed.

Name	Link
🔨 Latest commit	0a98c69
🔍 Latest deploy log	https://app.netlify.com/sites/vuejs-coverage/deploys/6398a007c728960008a3c030

[netlify]

❌ Deploy Preview for vue-next-template-explorer failed.

Name	Link
🔨 Latest commit	0a98c69
🔍 Latest deploy log	https://app.netlify.com/sites/vue-next-template-explorer/deploys/6398a0070e7569000932fc18

[netlify]

❌ Deploy Preview for vue-sfc-playground failed.

Name	Link
🔨 Latest commit	0a98c69
🔍 Latest deploy log	https://app.netlify.com/sites/vue-sfc-playground/deploys/6398a00732c73a0008c48e14

[github-actions]

Size Report

Bundles

File	Size	Gzip	Brotli
runtime-dom.global.prod.js	85.9 kB	32.6 kB	29.5 kB
vue.global.prod.js	132 kB	49.3 kB	44.4 kB

Usages

Name	Size	Gzip	Brotli
createApp	47.9 kB	18.8 kB	17.2 kB
createSSRApp	50.6 kB	19.9 kB	18.2 kB
defineCustomElement	50.3 kB	19.6 kB	17.9 kB
overall	61.2 kB	23.7 kB	21.6 kB

[sodatea]

This PR seems to have caused a regression in test-utils types:
https://github.com/vuejs/ecosystem-ci/actions/runs/6822057901/job/18553448341#step:7:3107

[pikax]

@sodatea I'll have a look and fix the regression

[pikax]

Fix here vuejs/test-utils#2240

[sodatea]

The latest vuetify ecosystem-ci failure is also caused by this PR: https://github.com/vuejs/ecosystem-ci/actions/runs/6873130528/job/18696834234#step:7:1112

[pikax]

@sodatea Interesting I think their usage is incorrect 🤔

The error is because defineComponent({ ...{} as any }) cannot be used in conjunction with Component

declare function test(O: Component): void

test(
  // @ts-expect-error errors here
  defineComponent({
    ...({} as any)
  })
)

test(
  // works
  defineComponent({
    ...({} as Record<string, any>)
  })
)

const c =  defineComponent({
    ...({} as any)
  })
  
// works
test(c)

I suppose this happens because because typescript can't simply infer the correct type, IMO casting as any there is not very good, since it's telling the defineComponent it can be anything, like functions, symbol, number, etc...

Not sure if we should even support that tbh.

/cc @KaelWD

EDIT: This is the overload before this PR it would pick up: