Any plans for adding TypeScript definitions?

[ali-habibzadeh]

Most serious projects use TS and would be nice to be able to use this lib in those projects.

Do you have any plans to add support for this?

[tagomoris]

I have no plan about it right now, but at the same time, don't have a strong opinion about it.
If someone wants to support it, I don't deny it.

[ali-habibzadeh]

We are writing one now. Would you like to ship it with your library or wants us to just add it to Definitely Typed?

[tagomoris]

@ali-habibzadeh I'm unfamiliar to TS. Could you explain the difference between those two?

[tagomoris]

#29 (just to note)

[ali-habibzadeh]

There are two methods.

1. Library ships with .d.ts files so when people install this module they get the types with it too (PR TS types #29 is proposing this approach). This method transfers the maintenance to you as well as you role new versions out.

2. We submit the types info to the the Microsoft Definitely Typed repository. This way people who want the types have to install 2 separate modules. So they do npm i presto-client & @types/presto-client. This method doesn't need you to care

Obviously we are TS devs so we think you should care :) but that's a choice for you.

[tagomoris]

Obviously, the 2nd option looks better for me because I'm unfamiliar to TS and I'm unsure I can maintain .d.ts files continuously when we took the 1st option.
I want to hear opinions from other people if possible...

[Amirault]

The second option is the best ! please choose two !

[Ekrekr]

I think the first option is better because having it in the same repo makes it easier to keep it up to keep the types up to date (no mismatched versions between types and this), and it won't have any regressive effect on existing javascript users.

If the types are wrong people will fix them!

[MasterOdin]

Given the lack of traction here and in #29, I've opened a PR at DefinitelyTyped to add types: DefinitelyTyped/DefinitelyTyped#65278

In my experience, unless the main maintainer of a library commits to keeping the types up-to-date, then it's better to have them be separate and there's a stronger signal of whether the types are out of date or not for a given version. This also allows the community to have better / easier turnaround on fixing the types.

pm2 is an example of a package that has its types as part of the module, but it's not maintained by the developer and PRs for types are often ignored / left to linger and so using it in TS is a huge pain.

[YenHub]

Nice work @MasterOdin 😎

That PR has now been merged 🎉

@tagomoris - is it worthwhile closing this issue in favour of the @types/presto-client?

Thanks for your efforts putting together this client, super appreciated!

[tagomoris]

Thank you, guys!