[FR]: TypeScript support

[janis91]

It would be very beneficial to add TypeScript support through a declaration file. I am currently working on porting my app to Vue.js based on TypeScript. I personally feel lot more comfortable with TS than plain JS and I think it might support other app devs as well, when they think about using this shared component lib.

---

Current state (updated by @susnux ):

• overall 66% (101 / 151)
  • components 43% (47 / 109)
  • composables 100% (8 / 8)
  • directives 100% (3 / 3)
  • functions 100% (16 / 16)
  • mixins 0% (0 / 5)
  • utils 93% (14 / 15)

[skjnldsv]

Hi @janis91. Thanks for raising this question!
Typescript rise the level entry rather quite high. We talked about it before and decided to not use it for our apps. Nonetheless, we do use it for our libraries @nextcloud/xxxxxx. So this questions is an interesting one to ask ourselves for the components library.

We don't get much contributors here and some components are already quite complicated.
How much work do you estimate to implement this here? Because we're all running on limited ressources and it's something to consider in the balance :)

cc @ChristophWurst @nextcloud/vuejs

[janis91]

Hi @skjnldsv.
I think there are a few things to consider:
Even though you don't have to use TS in your app, you can benefit from typings because of IDE autocompletion and checks based on them. So especially for libraries there is a benefit.

I'm not very familiar with authoring a component library or libraries that provide typings in general, so I can't say, if this is a big deal (considered the limited time). I think there are some alternatives:

1. Refactor / Rewrite the lib in TS to get types strongly connected to the code (lot of work initially; maybe some more work when developing in the future; potential contributors could be daunted, because they don't know TS, but on the other hand could also benefit from the typings, when contributing, because they'd get a lot more feedback directly, if everything fits code-wise)
2. Provide the declaration files loosely within the repo. (not much work initially; should be considered whenever something is changed API-wise; contributors might ignore this, but maybe no TS knowledge is needed to contribute)
3. Add typings to DefinitelyTyped. Much more loose from the repo. (like 2, but worse?)

I mean, as I am developing my app in TS anyway, I will have to provide some kind of declaration anyway within my project. Still, I won't type everything - just what I use / need.
I think it should be considered, moreover because Vue itself moves in the direction of TypeScript with version 3. This of course doesn't mean you'd have to use it in the future, but the community will be much more aware of it in the future, I guess.

Just my two cents.

[skjnldsv]

I think it should be considered, moreover because Vue itself moves in the direction of TypeScript with version 3.

Some reading about this? :)

[janis91]

Some reading about this? :)

https://medium.com/the-vue-point/plans-for-the-next-iteration-of-vue-js-777ffea6fabf

[skjnldsv]

The codebase is also now written in TypeScript. Although this will make proficiency in TypeScript a pre-requisite for contributing to the new codebase, we believe the type information and IDE support will actually make it easier for a new contributor to make meaningful contributions.

Thanks for the read @janis91 :)

[susnux]

What do you think, would this something for the next branch? If yes I can contribute the required changes (should be not too much work if we do the migration step by step).

cc @skjnldsv @raimund-schluessler @ShGKme

[skjnldsv]

@susnux depends on what we're talking about.
If this is only about typescript support and allowing it in components it's fine. I'd like to make sure thi sis not about using the same component syntax you used in dialogs as I think this is far too complex and raising the level entry too high :)

[susnux]

depends on what we're talking about. If this is only about typescript support and allowing it in components it's fine.

Yes exactly to keep it simply I just would allow using Typescript so that type definitions for our components are generated. Allowing users to write apps with first class Typescript support :)

I'd like to make sure this sis not about using the same component syntax you used in dialogs as I think this is far too complex and raising the level entry too high :)

As said this was not planed, but fyi I decided to use the script-setup style components in dialogs to make it easier for beginners to contribute, as it removed much boilerplate code and it is the recommended style for writing vue components. Meaning everybody who starts learning Vue with Vue 3 is probably using composition API and if started with Vue 3.3 probably script setup.

But I did not plan to rewrite everything using script setup here ;-)

[ShGKme]

I see both advantages and disadvantages of using TS in Vue frontend.

While it may help with developing some complex components and prevent issues, it increases complexity as well.

Another problem is mixing JS and TS in Vue. In some tools like ESLint, we cannot divide Vue JS and Vue TS components. For ESLint, both are just .vue files.

Allowing users to write apps with first-class Typescript support :)

Without full migration to <script setup> it doesn't change much for lib users. @nextcloud/vue has mostly only Vue components. props and emits may work without TS, typing slots works only in SFC Setup.

However, it is not required to write a library in TS to have first-class Typescript support for end-users. We only need to have typings somehow.

to make it easier for beginners to contribute, as it removed much boilerplate code

IMO, it is discussible. I don't think that Composition API is easier than Options API for beginners in general. I still see many developers who learn Vue with Options API first. And it will be a problem for the first time for full-stack developers and other contributors who don't "live" in Vue.

Especially when Composition API is used in new <script setup> with compile-time stuff.

<SFC Setup> reduces "boilerplate" but also loses a "structure" of Options API.

Though I really do not like SFC Setup with much of the compile time magic and macros, I must admit that it is a new "standard" in a Vue world, and new features are mostly SFC Setup related... Likely we will move to SFC Setup someday (some year :D) anyway.

---

So I'm fine with any solution here.

[susnux]

I created an example so you can see what is needed for Typescript support:
#4525

---

edit @ShGKme posted the comment the same time

However, it is not required to write a library in TS to have first-class Typescript support for end-users. We only need to have typings somehow.

That is true but then you have to maintain those type definitions, when using Typescript for the source you only have to maintain one place.

[ShGKme]

That is true but then you have to maintain those type definitions, when using Typescript for the source you only have to maintain one place.

I'm not sure that we cannot generate typings from JS and JSDocs. It definitely works in Pure JS, and may work in Vue, but I haven't tried it in Vue. So didn't propose to write .d.ts files by hand =D

[skjnldsv]

to make it easier for beginners to contribute, as it removed much boilerplate code

IMO, it is discussible. I don't think that Composition API is easier than Options API for beginners in general. I still see many developers who learn Vue with Options API first. And it will be a problem for the first time for full-stack developers and other contributors who don't "live" in Vue.

Seconded. This is why we had meetings and decided to go for sfc in the past. Because it's much easier for beginners.