Feature request: Provide TypeScript types
ristomatti opened this issue · comments
I'm currently in the process of converting a client codebase to TypeScript and this module was one of the few without typings (self contained or community provided). Are there by any chance plans to do this is the near future?
Thank you for your issue submission!
No, currently there are no such plans, but we would probably accept a PR with those changes. If you or someone on your team find it worthwhile to do that, please give us a quick notice before so we can discuss the approach a bit before you spend time on it.
Thanks!
Thank you for the quick response. Unfortunately I doubt I will be able to do this on a customer budget, especially in a generic enough way. Some level on typing will likely need to be done though. So if you already have some ideas of a specific approach, please let me know. With luck I might be able to take it into account, and then later try to make it more general purpose on my own time.
I have occasionally had pretty good results either using one or more of:
- generating interfaces from JSDoc
- using JS->TS migration tools, then refining by hand
- converting JSON request/response strings to TypeScript interfaces using IDE plugins
I have to note that at this point I do not yet have any experience using this library or knowledge of Loop54 API's so I don't have an idea if this would be a mountain of work. My approach to new code bases just often tends to first convert them to TypeScript to make it easier to reason about.
I do have some experience working with Apache Solr and Elastic search which will likely help on a contextual level.
We have not yet discussed or planned how - or even if we should - do this. Thanks for explaining your general approach - at first glance it makes sense to me but there are of course edge cases to consider, like how this would fit into our build chain and how it would affect other users of the library.
I suggest you make a fork of this repo and make whatever changes you need to start using it in the project. Once that's done you will probably know more about how the library works and how to use it. At that point we can maybe discuss again how and if we can merge back your changes?
And yes - the basic idea is similar to how you work with Solr and Elastic, though there are some differences. And the Loop54 API is much smaller than those, so it should be easier to learn. If you haven't already, I suggest you go through the documentation at http://docs.loop54.com to get a feel for what the API is capable of and some best practices.
There definitely is a lot to think about. Some thoughts to consider:
- How to support for both global (via
<script/>tag) and module use cases? - Should the goal either be a) very basic and "sloppy" types to allow using syntax not included with the types or b) to aim for good support and be extendable via generics to support available customizations?
- Could it affect other users of the library (like you mentioned)? Editors with good TypeScript support will nowadays likely grab and try to make use of the types even with JavaScript, potentially causing annoying warnings on perfectly valid syntax.
- How to make sure the types are properly maintained if the API changes? It can be a source of frustration when the documentation says one thing and your IDE says the synta is not valid.
- Does your team have enough TypeScript knowledge (or motivation to learn) to take the above into account?
But there's definitely business value in this also. How much, I cannot say but if you consider a potential customer with a TypeSript codebase making a decision on choosing between Loop54 or a competitor with a similar offering, something like this could be the tipping point. I'm more familiar with headless CMS service providers. On that area I've noticed the major players do support TypeScript OOTB.
From my point of view as a consultant working with a customer codebase, my primary goal is to support the use cases required for this specific use case. After going through the above thought process, I'm afraid there's very little for me to gain to take into account all the issues above, especially since there's no free plan available.
The situation would be different if our business would happen to focus on consulting work around the the services offered by Loop54, in which case taking a more active role could have some value for us, but this is not the case here.
With this said, if the API surface turns out to be small enough to relatively easily make the types generic enough to be useful I might still be able to provide a basis for your team to work further if something like that would be useful? One way to aproach this would be to merge the change onto a separate branch for the work to continue and perhaps be of use to someone else facing a similar issue as I am now.
I really appreciate your effort looking into this, and your analysis of the considerations is spot-on! I do agree hat providing a TypeScript version of this library would be beneficial to many implementers, and as you say could be the tipping point that makes a customer choose us instead of a competitor. However, we're a small team and have to focus on the most value-bringing work and currently I don't think that this is it - especially since TypeScript is not widely known in the team. I have opened a ticket internally so we can track how often we get this request and be able to take action once we see that the demand is high enough.
That said, we will of course offer any help we can in implementing with the existing library, or any changes you might want to do in a fork - I just don't want you to spend your valuable time working on this, just for us to drop it when you hand it over. I hope that makes sense.
I just don't want you to spend your valuable time working on this, just for us to drop it when you hand it over. I hope that makes sense.
Thank you for the thought out reply. This makes perfect sense to me and I also appreciate considering this aspect.
I have opened a ticket internally so we can track how often we get this request and be able to take action once we see that the demand is high enough.
One reason why you might be seeing low number of requests for Typescript might be the fact this repository is not straightforward to find. Firstly and most importantly, it's not linked to your npm package (package.json is missing the repository section). Another thing is that the repository name does not match the library name. If you try googling for "loop54-js-connector" this won't show on the first page. You'll specifically need to add "github" as an additional keyword to find it.
One reason why you might be seeing low number of requests for Typescript might be the fact this repository is not straightforward to find.
Thanks for the pointers! We do want it to be easy to find. Will add an internal ticket for this as well.