Drop typing for component in mount

[lmiller1990]

Ref: #272

Related:
#237
#194

I think we should consider typing the first argument in mount as any. As it stands, you often need to use ts-ignore or any. This is also a problem in other code bases, like testing-library/vue, where the API is like this:

const { emitted } = render(Foo)

expect(emitted().foo[0][0]).toBe('...') // <- you must ts-ignore this

Neither of the libraries can be considered stable with many typing errors out of the box for basic use cases. A lot of work went into typing mount but the tooling around SFCs seems to be a limiting factor and I don't think this will change in the next month or two, when Vue 3 is supposed to become the "main" release and the other core libs are expected to become stable (router/vuex/test utils). Alternatively, maybe I am over-estimating the scope of the problem? 🤷‍♂️

I personally haven't had too many problems around mount, but it seems many other users do, and explaining it is outside the scope of VTU (eg tooling) is not a good look. If the tooling for a feature isn't ready, I don't feel super confident implementing the feature - hardly anyone can take advantage of it, compared to the number of people have problems.

The goal here is to remove any blockers from hitting a stable 2.0.0 in the month or so, and this is the main blocker as it stands.

@afontcu @cexbrayat @pikax @JessicaSachs @TheDutchCoder may have some input/opinions? I really enjoy TS and have no desire to go back, but I foresee the current typed mount causing more problems than it solves. We can keep the types in a branch until the tooling is at a point where we can bring them back without causing problems.

[cexbrayat]

I get your point, and I'm fine if this is the option picked.

I don't know testing-library/vue, but why whould you want any there? emitted should return Record<string, unknown> no?
(in the best case it would return Recor<'foo'|'other', unknown> but SFC...)

I personally think any is a bad choice for an API, and it will be hard to come back from it. As a TS user, I definetely expect it to not be any :) It would break developers who don't want to use SFC (pure TS file, or TSX), as we currently have proper types (even if far from perfect).

[lmiller1990]

Is there a less bad/relaxed choice that is better than any? Can we get away with the current type | unknown? Or just unknown? I just ayn chose it off the top of my head, would be with something different - idea is just to not let TS get in the way of less experienced users.

For testing-library/vue, probably Record<string, unknown> is fine. Long term, we can hopefully extract the types from emits if it is defined (this should be possible right now for components that are not SFCs).

[afontcu]

fwiw,

VTL for Vue 2: I guess this could be improved from any[][] to Record<string, unknown>? https://github.com/testing-library/vue-testing-library/blob/master/types/index.d.ts#L34-L35
VTL for Vue 3: offers EmitsOptions (from Vue core) https://github.com/testing-library/vue-testing-library/blob/next/types/index.d.ts#L27

---

That being said, it looks like getting types right is hard (even though you folks are doing an amazing job about it), but most issues come from edge cases which we should expect (we're in beta, after all!).

[TheDutchCoder]

I can only give my input as a total noob to TS, so take all of this with some grains of salt please :)

As a user, the underlying issue is the following: TS is great and I think many of us see the (multiple) benefits of using it. It's also a little hard to pick up for a lot of us and the learning curve seem gentle enough when you read the handbook, but in practice it's near impossible to wrap you head around all the super complex typings you find in a lib like Vue.

This combined with the "push" for using TS, using SFC's, and writing tests leads to a situation where users not only have to learn this new TS thing, the tooling is actually hampering them in understanding what's going on.

And I'm not pointing fingers here, I'm just describing the feeling as a user. It feels like I'm supposed to write Vue3+TS+tests (and I actually agree with that), but at the same time I've now spent around 3 days even getting the tooling to sort-of help me, instead of fight me.

Coupled with TS integration in VSCode also not being great with Vue3+TS+tests (you need a plugin in alpha stage to even half-work) it's just (currently) not an ideal situation.

Of course, this hits on a lot of points outside of VTU, so let's disregard that (just trying to give a complete image here).

As far as VTU goes, I have to still dive into the details. I've had some good success in the (non-TS) past with VTU, so we'll see if I hit snags with TS specifically.

But I agree, if I have to end up writing my tests and litter it with TS-ignores and any, then I don't think writing in TS is useful. It might still offer some marginal advantage, but don't forget that it's quite a pain to set it all up already and if people then finally get the tooling to work and find out that TS in your tests was a bit of a waste of time, then I think it's doing more harm then good.

Just a question (that I also posted in the issue thread): how come Vetur is able to correctly infer types from SFC's? Don't they also just rely on the TS parser? Or are these things very different?