chore: use experimentalExposeScriptSetupContext for vue-tsc

[cexbrayat]

This new option allows a better typechecking of components that expose variables.
See vuejs/language-tools#805

Refs #972 as this partially fixes it

[cexbrayat]

@johnsoncodehk I gave a try to the option, as we have a test file expose.spec.ts in the codebase that was not type checking previously (and was excluded form what vue-tsc checks).

Using the option, 2 errors went away 👍

We still have one unexpected error, for a component defined with defineComponent and exposing its variable with expose: in that case, vue-tsc still thinks wrapper.vm does not have access to the property:

tests/expose.spec.ts:28:23 - error TS2339: Property 'other' does not exist on type '{ $: ComponentInternalInstance; $data: {}; $props: Partial<{}> & Omit<Readonly<{} & {} & {}> & VNodeProps & AllowedComponentProps & ComponentCustomProps, never>; ... 10 more ...; $watch(source: string | Function, cb: Function, options?: WatchOptions<...> | undefined): WatchStopHandle; } & ... 4 more ... & ComponentC...'.

28     expect(wrapper.vm.other).toBe('other')

It also raises an error that was not existing before in emit.spec.ts, where we have [EmitsEventSFC, EmitsEventScriptSetup] as DefineComponent[]:

tests/emit.spec.ts:349:11 - error TS2352: Conversion of type 'DefineComponent<{}, { click: () => void; }, {}, {}, {}, ComponentOptionsMixin, ComponentOptionsMixin, "bar"[], "bar", PublicProps, Readonly<...> & { ...; }, {}>[]' to type 'DefineComponent<{}, {}, {}, ComputedOptions, MethodOptions, ComponentOptionsMixin, ComponentOptionsMixin, ... 4 more ..., {}>[]' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.

349   it.each([EmitsEventSFC, EmitsEventScriptSetup] as DefineComponent[])(

We can workaround all this, but maybe that should be fixed in vue-tsc?

[lmiller1990]

Should we be ts-ignoring these or is there more work to come (maybe in Volar) before merging this?

[cexbrayat]

This one is expected to not compile without as, as the test is just to check it is not exposed 😉 So I think it's fine to explicitly cast it to make TS happy.

[cexbrayat]

@johnsoncodehk mentioned on Discord that the first part of the issue is an upstream one vuejs/core#4397 (comment)

I think I'll rewrite the test to get rid of the second one, and maybe ts-ignore the first error while we wait for the issue resolution in vue-next

[cexbrayat]

Done. At the price of one ts-ignore due to the upstream issue, vue-tsc is now capable of type-checking all our tests and components. I also had to rewrite a test to split it in 2, but I don't think this is big deal.