test(reactivity): support passing object with only one get property

[chenfan0]

No description provided.

[github-actions]

Size Report

Bundles

File	Size	Gzip	Brotli
runtime-dom.global.prod.js	85.8 kB	32.6 kB	29.5 kB
vue.global.prod.js	132 kB	49.3 kB	44.3 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

[sxzz]

Why? It's necessary.

[jacekkarczmarczyk]

If it's necessary and tests still pass after removing it maybe there should be a test for this?

[sxzz]

Yes. Add the case:

import { computed, isReadonly } from 'vue'

const a = computed(() => 1)
// @ts-expect-error
const b = computed({ get: () => 1 })

console.log(isReadonly(a), isReadonly(b))
// Both should be true

[chenfan0]

Yes. Add the case:

import { computed, isReadonly } from 'vue'

const a = computed(() => 1)
// @ts-expect-error
const b = computed({ get: () => 1 })

console.log(isReadonly(a), isReadonly(b))
// Both should be true

If the ts type is strictly adhered to, then this setter is unnecessary. If it is not strictly adhered to, should the key of the WritableComputedOptions<T> be changed to optional?

[sxzz]

We encourage users to use computed(() => 1), but if they're using computed({ get: () => 1 }), we cannot break the existing app either.

I think keeping existing cases is for greater robustness.

[skirtles-code]

I think the scenario tested by a is already tested by it('should be readonly'. I think that part can be removed here.

I also wonder whether the test for b should just be merged into it('should be readonly'? Or, if not, maybe move this test case to be next to that one?