Any update on this? I'm more than happy to contribute if possible, so we can remove disclaimers like this
https://itty.dev/itty-router/guides/cloudflare-workers

@kwhitley Just to check, does itty-router have a middleware property?

It does not, but it has a proxy prototype that will intercept a request to middleware and return a function. So to the outside, it looks like we do have that property... as a function.

A tiny safety check that confirms that middleware is iterable before iterating should work here though (because that check would fail if it's determined to be a function).

We can definitely add that check (as the linked PR does), but is there any reason itty-router returns a function for the middleware property? Ideally it should only return a function for the fetch property, and pass through to the underlying object otherwise

Itty allows (unknown) properties to be read off the underlying object as methods/route handlers, in order to maintain its tiny footprint and support virtually any current/future HTTP verb.

For instance, accessing router.post responds with a route handler (function) that will ultimately register on the POST http method. Likewise for any other attributes not defined on the underlying object itself, so router.middleware is simply interpreted as the user trying to create a route handler matching the MIDDLEWARE http method :)

This is why our current wrangler dev workaround of export default { ...router } works, even though it looks pointless. It strips off the proxy prototype from the object, returning only the current tangible values, and none of the intercept behavior. A bit of random trivia there!