Is this package maintained?

[danbars]

I see that PRs are generally merged, but there are quite a few open issues.
The statement is that this package is used in production in Cloudflare Radar.
Radar is fairly simple in terms of API complexity - it has quite a few endpoints, but all of them are just GET requests used to fetch data.
Many of the open issues evolve around more complex scenarios - different content types, empty responses, file upload, custom headers, etc.
So my question is this - is this the intention of the package owners to support wider use cases than what Radar needs?
Does the team actively investing time in it, or only if it happens to be needed by a feature in Radar?
I really like the package, but I prefer knowing upfront what I'm getting into.
Thanks

[G4brym]

Hey @danbars
Besides Radar, this package is already used by more teams inside Cloudflare like URL Scanner, Workers AI and Ai Gateway and more.
This package will soon be the default way to build new api workers internally at Cloudflare.
There are also a lot of projects from the community that use itty-router-openapi, for example I built r2-explorer backend worker with this, and as you can see the api has much more complex use cases than radar.
I also see that some of the open issues are documentation issues, as the users are describing use cases that is already supported, but the documentation isn't updated to show that.

The biggest problem, was that for the last few months, I just didn't have much time allocated to continue adding new features to this package, or improve the documentation.

So answering your questions, yes we intend to support wider use cases, as more teams internally at Cloudflare are now depending on it.
Being honest, we are currently, only investing time in this package when a breaking bug is reported, or when an internal team asks for something.
I've no clue about the future, but as this package continues growing in users and more customers start depending on it, its priority will also grow inside Cloudflare and more people might get allocated to work on it.

[osseonews]

Thanks for the comments @G4brym What I am confused about now is whether to use this package or Hono for routes on Cloudflare Workers? Many of the examples on Cloudflare's website now feature Hono, but in reading your comment, the teams internally at Cloudflare use this package and it will the default? I'd rather use something that is used internally at Cloudflare, as opposed to some other package, though it seems like the people who are building Hono also work at Cloudflare?

[G4brym]

Hey @osseonews the people who are building Hono also work at Cloudflare
Despite this being the default option for new projects inside Cloudflare for building API's, teams are also free to pick Hono or any other library for routing, there are definitely a lot of projects using Hono internally
itty-router-openapi is mostly focused on building API's and validating inputs and this will probably never change, while Hono has a much wider use cases, like single page apps, server side render, etc
Hono is used in many examples on our docs because it supports the most use cases and applications
I think you should pick whatever you like the most and whatever fits best in your project

[osseonews]

Thanks for the quick comment. I actually used to use itty-router, but then jumped to hono recently, because I thought that was the only thing Cloudflare was going to standardize on. So I appreciate you sharing this information. I think I might move back to itty-router now, as it is just much simpler to use.