Update Vetur type inference for SFCs

[ferdaber]

The Typescript guide says that exporting Vue.extend({...}) will no longer be necessary in Typescript-based SFCs due to Vetur having correct syntax highlighting and type inference. Despite the fact that Vetur deals with this correctly without wrapping, the Typescript compiler will produce an error when the default export isn't wrapped, presumably because it does not make the same assumptions as Vetur.

The official Typescript Vue starter guide references this as well, stating that Vue.extend({...}) is still required even with Vetur.

This change is to remove that snippet in the Typescript guide so that users aren't confused that their Typescript compilers are erroring out despite Vetur working correctly.

[chrisvfritz]

Happy to merge with approval from @octref.

[HerringtonDarkholme]

I wonder under what situation TS would throw errors, since the typing definition we provide already accepts plain ComponentOptions.

[octref]

@HerringtonDarkholme I guess he meant TS won't compile for

export default {
 ...
}

Is that true that there is no way to config TS to support it? I haven't used much TS + Vue in combination yet, and when I was testing I was always using Vue.extend in TS blocks.

[ferdaber]

@HerringtonDarkholme the two cases I found that created the error are:

Exporting a default object and later using that as a Vue constructor:

<script lang="ts">
// App.vue
export default {
  // ...
}
</script>

// index.ts
import App from './App.vue'
new App({
  el: '#app'
})

gives an error:

TS2351: Cannot use 'new' with an expression whose type lacks a call or construct signature.

Exporting a default object for a component that references this and then later importing that component:

<script lang="ts">
// Message.vue
export default {
  data() { return { message: 'Hello' } },
  methods: {
    clearMessage() { 
      this.message = '' // problematic
    }
  }
}
</script>

<script lang="ts">
// App.vue
import Message from './Message.vue'
// ...
</script>

gives an error:

TS2339: Property 'message' does not exist on type '{ clearMessage(): void; }'.

In general it looks consistent that exporting a default plain object leads Typescript to not infer (even from the 'vue-shim.d.ts' ambient module declaration) that the object itself is a Vue type. This is my module declaration FYI:

declare module '*.vue' {
    import Vue from 'vue'
    export default Vue
}

[HerringtonDarkholme]

@ferdaber Yes, using this will break ts-loader compilation, because Vetur's wrapping only affects editor, not ts-loader.

Vue.extend seems to be required for ts-loader users for type checking. Only JS users or transpile-only TS users can benefit from Vetur's editing.

Maybe we can just remove the Vetur section? So TS users (I guess most of them do type check at ts-loader) will not be confused.

Is removing ok? @octref @chrisvfritz

[octref]

I agree with removing. On the Vetur side we should separate TS mode from JS mode and stop the default wrapping in TS blocks, so that people wouldn't be "fooled" by Vetur.

That default wrapping is only meant for JS.

[ferdaber]

Changed the file to remove the entirety of the Vetur section.

This is probably not the forum for this but I'm curious still as to why the TSC will still throw a compile time error when importing a .vue file and using it as a Vue constructor (see the App example above). I had thought that using the module shim allows TS to cast whatever is imported with a .vue extension as a Vue constructor?

[HerringtonDarkholme]

Probably because ts-loader will read the script content in the vue file rather than reading from module declaration. This is ts-loader's feature.

If you encounter this without webpack and ts-loader, please let me know how you do that.

[ferdaber]

Awesome, thanks for the clarification!