🚩 Unmaintained?

[SpazzMarticus]

@ajaishankar if you are maintaining this repo please close this.

Since weekly downloads of openapi-typescript are on the rise and this repo is consuming its output a word or two about the future of this repo would be appreciated - I guess by others too.

Thanks in advance!

[kirypto]

I'm having some minor issues with type resolution using OpReturnType and OpArgType when I updated to Angular 15. I suspect an update is needed, but there has been no movement here. There are quite a few forks though, does anyone know if any of them are semi-maintained and could be a replacement for this one?

Hopefully @ajaishankar could get involved again and open this up to let others maintain it.

[mithodin]

@ajaishankar has been active on github recently, so at least it's not a case of the bus factor taking another FLOSS project offline. If you are looking for co-maintainers, I'd be up for putting in some work as I use this in a few professional and private projects.

[Rendez]

There are many valuable PRs we've opened since the maintainer last contributed. A co-maintainer would be ideal to get this through and merge, and that is the right path forward. However, in the meantime I propose that we temporarily guide one of the forks forward - some whom offers him/herself to be the release coordinator (RC) - and merge it back whenever the maintainer has time/interest again.

To that end, these PRs would be in my opinion prioritary:

• package module compat. and exports entrypoints #59
• Fix strictness of query params #55
• Improve strictness + add CI through GitHub Actions #51
• Enable FormData as input #50
• Support file downloads #46
• feat: Explode query string #44
• infer json definition for all parameters #40
• Fix OpReturnType to support 202 status code #36
• fix(fetcher): do not send json content type with empty body #19 #20

I see that @fedorg was active here creating his own release.

Thoughts?

[aurabirb]

I will merge all of these changes into my fork just for you :)

[dgee2]

Is there a plan for someone to take over the maintenance of this package? I appreciate this is a slightly awkward situation until we hear from @ajaishankar but understand that the workload of a maintainer often covers things that are not visible to all

[nilsmehlhorn]

For reference, there's also now an alternative by the maintainer of openapi-typescript called openapi-fetch

[djMax]

(That one is missing middleware, which is very useful)

[TheParad0X]

Any good alternative with interceptors? 😶

[Rendez]

I've released the package under our org https://github.com/qdrant/openapi-typescript-fetch and I plan to do my best to maintain it. The reason: this package fits our use case best and IMO it's a good middle ground between feature-rich and small size. There are loads of additions and improvements we can add, I know I've left some behind, so please issue them again against our repo fork. Here is a summary of the state of the fork (release 1.2.0) at this point in time:

• package module compat. and exports entrypoints #59
• Fix strictness of query params #55
• Improve strictness + add CI through GitHub Actions #51
• Enable FormData as input #50
• Support file downloads #46
• feat: Explode query string #44
• infer json definition for all parameters #40
• Fix OpReturnType to support 202 status code #36
• fix(fetcher): do not send json content type with empty body #19 #20

I've included every contribution and mentioned contributors in the package.json.

[prokhn]

@Rendez Thanks for your fork! I saw you changed npm to pnpm, is it necessary? The original package is using npm

[Rendez]

You can use whichever package manager you wish: npm or yarn. The original package can continue to use npm, but as long as we're publishing we prefer pnpm.

[RobinClowers]

@Rendez thanks for working on your fork! I don't see an issues tab on your fork though, is that something you can enable? I discovered what appears to be a bug in the types that I'd like to file (and maybe fix myself).

[Rendez]

@RobinClowers done.

[hmaack]

(That one is missing middleware, which is very useful)
Any good alternative with interceptors? 😶

This chapter looks promising — I will give it a try @djMax @nilsmehlhorn