Better TypeScript integration and API generation

[septatrix]

Currently the TypeScript integration is decent albeit not perfect. I feel like it could be improved in several ways while reducing maintenance burden and increasing DX. Currently the API and types are generated from manually curated JSON files for each component/plugin/composable. This unnecessary duplication not only takes time but is also error prone and may easily get out of sync if not watched carefully.

The workflow for API and type stub generation could be improved if the documentation would instead be moved inside the component files and extracted from there. With the release of v2, an incremental migration to TS was announced which could also help in this endavour.

Quasar v2 will lay the fundations needed for a Composition API + TS + tests incremental migration, which will take place during Quasar v2 lifecycle.

Originally posted by @IlCallo in #7836 (comment)

Instead of manually setting the type in the JSON file, it could be directly inferred from the component definition. Not only would this reduce maintenance burden, it also allows more precise types. For some of these scenarios where the JSON format does not provide sufficiently detailed types, there are currently manual stub files such as the one for QTableColumn. The need for these files would also no longer be necessary when transitioning to TS.

Another great benefit would be that the defineComponent has gained support for generics in recent Vue 3.3 betas. This can be used to provide type safety for events. E.g. currently an update event emits value any whereas with generics support it could be made to emit values of the same type as the provided model. Similarly template slots like they are used in tables could provide better type safety.

---

I know that this is a large undertaking. However, given that it apparently is already planned for the Quasar v2 lifecycle, I would be curious if where this is currently on the roadmap and invite to discuss more about the benefits and challenges this might bring. Personally, I definitely plan to play around with the generic support for defineComponent and try to implement a script which extracts documentantation from Vue components for one of our existing project and would be happy to provide them if I get a working pipeline going.

[IlCallo]

We already explored the topic and actually moved some steps in that direction, @yusufkandemir was the one experimenting on that
As I wrote in the comment you reported, the foundations are already in place, but unluckily that's not a thing we plan to work on this year

The migration to ESM which is currently going on is a step towards making the TS migration easier

[septatrix]

Happy to see that it's still on the radar!

[septatrix]

Regarding the topic of generic components, slots and events: This is now stabilized as of Vue 3.3

[septatrix]

@yusufkandemir have you by chance taken a look at the generics support in Vue 3.3? I am not experienced with how the d.ts files are generated for quasar, however, based on a bit experimenting on my end so far with vue-tsc it seems like it shouldn't be too hard to expand the current scripts and provide more precise typing. If that is not too hard it would be a great solution to bridge the time until a more large-scale TS migration is started.

[IlCallo]

We got word from Vue team that Vue 3.4 will have some more TS fixes and optimizations, so we'll wait for that one to be released before acting on the new generics support