wip: data typing issue #200
Conversation
| @@ -1,6 +1,8 @@ | |||
| import { expectError, expectType } from 'tsd' | |||
| import { defineComponent } from 'vue' | |||
| import { mount } from '../src' | |||
| // @ts-ignore | |||
There was a problem hiding this comment.
Is it necessary? TBH I don't like @ts-ignore even less in dts tests where we're supposed to check that everything works :) I'd like this to work without it.
| import Vue from 'vue' | ||
| export default any | ||
| const component: any | ||
| export default component |
There was a problem hiding this comment.
unrelated: Maybe we should use the same shim as the one provided by the CLI. It is not cast as any I know, but that would help catch errors that developers will encounter.
There was a problem hiding this comment.
I think Component is a better candidate, but needs testing
There was a problem hiding this comment.
From what I can tell since the shim gives you no information about your component (eg props/data/whatever) the majority of the types we have are not very useful. in my experience the vast majority of people are using vue files.
I think we are focusing too heavily on "correct typing" and not enough on the actual DX. At least from my point of view, I would rather not have type safety than have random ts compile errors even doing the most basic of things (like using data).
I wonder if there is some way to ignore all the mounting types when the imported component is from a vue file? That would really be ideal, at least at this point, since you cannot get any useful information from an SFC right now.
There was a problem hiding this comment.
without a typescript plugin that will handle vue files, I doubt we can extract much information from a .vue file.
The shim only tells the typescript: "this file import is of this type" - without any process.
There was a problem hiding this comment.
I think we need to merge something (this or something better?) sooner rather that later... using data to set a component up for testing is basically the Hello World of VTU and it doesn't work out of the box atm. I do not want to ruin the hard work that has gone into typing VTU, though, with ts-ignore and any etc... 🤔
This lets you use
datawith SFC imports as described in #194, but breaks the type safety for non SFCs. This seems unavoidable - I don't see how we can have the best of both words here, really.I don't see a good solution for this in the short term, unless someone has figured a good way to extract type info from
.vuefiles (not yet, or at least not stable yet).Any ideas? Using
vuefiles is much more common than using components defined with render functions, but I really value strong typing as well. I wonder if there is some way to not have as string type-checking for.vuefiles (using a shim). Eg: disable mounting option checks for shimmed vue files. I will do some research.@cexbrayat @pikax would love some input.