Refine Router type so it allows declaring what the RouteHandler return

[jrencz]

Summary

I propose so that there might be

Router<TRequest = Request, TMethods = {}, TOutcome = Response>

to allow strong typing what router handle produces without a need to rewrite most of types delivered with package.

Details & motivation

Right now there's

itty-router/src/itty-router.d.ts

Lines 5 to 7 in 2a51d57

	export interface RouteHandler<TRequest> {
	(request: TRequest, ...args: any): any
	}

It doesn't allow to declare what do methods of router (which conform RouteHandler ) return.

Then there's

itty-router/src/itty-router.d.ts

Lines 44 to 50 in 2a51d57

	export type Router<TRequest = Request, TMethods = {}> = {
	handle: (request: TRequest, ...extra: any) => Promise<any>
	routes: RouteEntry<TRequest>[]
	all: Route
	} & TMethods & {
	[any:string]: Route
	}

and in handle: (request: TRequest, ...extra: any) => Promise<any> the Promise<any> is the same any as any-the-return-type of RouteHandler

As I can see, having any there allows me to use itty-router to route requests into something that's not a Response.
I mean: that's good for me that Response is not enforced:

interface RouteHandler<TRequest> {
  (request: TRequest, ...args: any): Response
}

because then I'd have some problems (more at the end of post).

But: the way it is now doesn't allow me to explicitly declare what my router produces, but by doing something like this (which I actually do):

type Outcome = { /* clipped */ }
type MyRouter<TRequest = Request, TMethods = {}> = Router<TRequest, TMethods> & { 
    handle: (request: TRequest, ...extras: any) =>  Promise<Outcome>
}

export default new Router() as MyRouter;

And it keeps the handle protected. But type assertion is a poor man's choice.

In order to type-check the return type of each RouteHandler - at least with my current TS skills that's best I came up with - I have to

• declare return type on each of them (not quite scalable, not even speaking of rigidity), or
• redefine the Route type, then define IMethods and alter all existing keys, then pass IMethods to Router<..., IMethods> (which, yeah, is doable, but it seems that ability to pass IMethods there was added to make custom methods strongly-typed, not to rewrite Route)

Anyway: I build a solution that uses itty-router to select some kind of configuration for tools that will alter the intercepted response in my worker. Configuring it with the router-alike syntax seems like a good choice for my case