fix(types): prefer normal component over functional one

[HerringtonDarkholme]

What kind of change does this PR introduce? (check at least one)

• Bugfix

Does this PR introduce a breaking change? (check one)

• Yes
• No

Other information:

Background:
vuejs/vetur#676
vuejs/vetur#627 (comment)

TypeScript cannot give reasonable completion for Vue.extend. For example, methods, data will not appear in completion list. This is caused by the intricate overloading resolution in compiler host. microsoft/TypeScript#8005.

This problem will probably not fixed in foreseeable future. So we can work around this by placing normal component option before functional component. In most case, normal component option provides better completion. However, this will break type inference for functional component definition.

By providing an additional argument in normal component's render, we can at least compile functional component. Unfortunately, this work around will skip checking RenderContenxt. IMHO Vue's type checking isn't primarily for checking but for completion and definition looking up. So I think this is a advantageous trade-off.

[ktsn]

We should also reorder Vue.component overload, shouldn't we?

[HerringtonDarkholme]

Hmm, this reorder is not cost free. It will break functional component's type inference: context is inferred as RenderContext<any>. Vue.extend is used in Vetur and is recommended to TS users. So the benefit seems to exceed the cost. While new and component isn't used directly in editor service, so completion doesn't have the same priority I think.

[ktsn]

Oh, I didn't notice the functional component's inference will be broken. Hmm, I'm not sure we should merge this change, then... After this change, the prop types of functional component will not be checked, will they? I don't know how many users rely on it but I personally rely on Props inference of RenderContext well.

[HerringtonDarkholme]

After this change, the prop types of functional component will not be checked, will they?

No, they will not.

I can change it to be checked. However, normal component's render function will still have non-existing context argument in types.

[ktsn]

IMHO, allowing non-existing context in normal component is acceptable since the users probably not want to check it by type checker. But props should be checked since users probably change props' name/type during maintenance and want to use type checker to help the refactoring.
So I think it's ok if at least prop types are checked.

[yyx990803]

@ktsn do you think this is ready to merge?

[ktsn]

LGTM 👍