TypeScript codegen

[sekunho]

Hello!

Would it be a good idea to maintain something like servant-ts rather than just servant-js, especially since TS transpiles to JS anyway? Also given that TS' adoption has been on the rise over the past few years.

Is there also any way I can help with this?

(Thanks for maintaining servant and friends too!)

[alpmestan]

Hi! Is servant-ts unmaintained? If the package is indeed not maintained, we can look around for people willing to help with the maintenance of that package, first. It's not entirely obvious to me that the package would benefit from living along with the core packages. servant-js happens to live in the repository because I wrote it veeeery shortly after the core packages (because I needed it) and never moved it out.

[sekunho]

By the looks of it, yeah. I know commit activity is not really the only indicator in this, but the last commit was 3 years ago, and it's still on 5 LTS versions ago. It doesn't seem to be on Hackage/Stackage as well. Same story with aeson-generic-ts.

[sekunho]

servant-js happens to live in the repository because I wrote it veeeery shortly after the core packages (because I needed it) and never moved it out.

Is this also what happened with servant-elm?

[alpmestan]

There is https://github.com/smaccoun/servant-ts and https://github.com/micahhahn/servant-ts AFAIK. The former has the most recent commit (from last year), and the playground still available online. Neither have been uploaded on hackage though indeed.

@smaccoun (sorry for the mention "out of nowhere") Are you still actively maintaining your servant-ts repo?

---

Regarding:

Is this also what happened with servant-elm?

I didn't write that one and it never lived in this repository. Not sure what the status of that package is, we'd have to get in touch with the current/last maintainer, if any.

---

More generally, this brings up the question of how to guarantee that the frequently used "satellite packages" never lag too far behind. Ideally we not only want them to build, but also have them support the latest combinators and what not.

For the "they build" side, Oleg had https://github.com/phadej/servant-universe - and this is in my opinion the kind of thing we want, as opposed to just bringing everything in the main servant repo (we'll quickly hit CI time limits and since servant has always operated with a whooping 0€ of funding, we cannot afford paid plans). For the "they are up to date feature-wise", it seems to me like we'd need a super-charged example application or testsuite that tentatively exercises everything, to make sure all combinators have instances for all the interpretations, etc. But that's a non trivial amount of work.

[sekunho]

I may have worded this a bit incorrectly. This is more on filling the gap for TypeScript codegen, rather than bringing the project into the main servant repo. Since if one wants to generate TS functions + types, there's nothing besides seemingly experimental packages (I'm not sure what they're intended to be, hence why I'm calling it experimental), unlike servant-js and servant-elm. Although, I guess for my use case, I can try to update one of the existing packages to a recent GHC version.

we'll quickly hit CI time limits and since servant has always operated with a whooping 0€ of funding, we cannot afford paid plans

Would be cool if the Haskell Foundation could help with that if ever it's a huge problem.

Oh, and I wasn't sure where to open the issue for discussion since the organization doesn't have a global issue tracker, so I decided to just do it here. I can close this if ever this isn't the appropriate place.

[alpmestan]

Aaaaah, I see.

Well I have been involved in projects that used servant-ts (the most recently updated one) successfully, with ghc 8.10, in the past 2 years -- although I wasn't the one who wrote the code using it. So I suspect the package might only require small tweaks to make it build with more recent GHCs if it doesn't yet, and you should be good to go. If the current maintainer is still active you can make a PR, and if not you can ask about taking over or at least getting the appropriate rights to be able to make new releases. But yes I think you should look into that package as it will definitely be a more than decent starting point.

---

Would be cool if the Haskell Foundation could help with that if ever it's a huge problem.

Well it currently isn't a problem and I don't think we want all the servant packages ever written to land in this repository for various other reasons anyway. Also, if every single library that's quite used in the wild starts asking the HF for CI money, that will quickly become a problem. I think the current state of things is good enough.

---

Oh, and I wasn't sure where to open the issue for discussion since the organization doesn't have a global issue tracker, so I decided to just do it here. I can close this if ever this isn't the appropriate place.

That's absolutely fine, don't worry. :-)

[sekunho]

It's reassuring to hear that you tried out one of them, so I'll give it a shot. Thanks for your time!

[smaccoun]

Hi all, I'm sorry I'm so late to the discussion on this. Moreover, I'm sorry that I've been so neglectful with those libraries. Every time I thought I'd have some time to work on them, sure enough something came up and it got pushed back. I just updated the READMEs to say that I am not maintaining them any more and looking for a maintainer :(

At this point I'd love for someone to adopt or maintain them, steal code from them, fork, or whatever really. I don't think I can make any promises to help but if someone picked one of them or brought ts into servant in some way, i'll keep my eye out and contribute where I can. I would love to say i can get something over the line with these but am more worried about an empty promise when life things seem to keep happening.

Glad to see the energy here and would love for typescript codegen to be a viable part of servant!

[sekunho]

@smaccoun No need to apologize for that! It's understandable, really.