Typescript router "Additional types" are ignored

[paulrostorp]

Describe the Issue

Following the typescript example for "additional types" (https://itty.dev/itty-router/typescript):

Example Router Code

type CF = [context: ExecutionContext];

const router = Router<IRequest, CF>();

router.get("*", (req, ctx) => {
  return new Response("foo");
});

In the code above, the type of ctx is any.

In router.handle, the type is propagated properly

Expected Behavior

The type of the second route handler argument should be of type ExecutionContext.

Actual Behavior

The type of the second route handler argument is any.

Environment (please complete the following information):

• Environment: Cloudflare Workers
• itty-router Version: 4.0.23

[kwhitley]

Weird... in our own example testbed, we have a situation that mirrors your own. We can see it working fine here:

[kwhitley]

Oh wow... when switching the first param to use/union IRequestStrict (shown above) instead of IRequest (default, and what you used), it works... definitely a bug. Good catch!

[kwhitley]

So this stems from the following:

• In TS there is no way to detect if a user has passed in a generic (which we want to detect)
• so we were checking for equality against IRequest (the default)... if this passes, we assumed the universal route pattern was not being used, otherwise we used it. This is naive, as:
  • we should consider both the request-type (first arg), and the second arg
  • if either args are not empty (default), or the first param is not IRequest, we should use universal, as a change has been made

[kwhitley]

Solution

I've modified the type definition to explicitly check both the first and second param. If either have been modified, it uses the universal route.

This will roll out in 4.1x with several other changes - great catch @paulrostorp!

[kwhitley]

Found some issues, so this created a deep dive...

I've done a pretty heavy rework on the internals, which now allows a MUCH more robust usage.

Changes:

• a router-level global generic can now be used, period
• route-specific generics can then be used on a per-route basis to override

[malobre]

@kwhitley Are the changes you mentioned on the v4.x branch?

[kwhitley]

These are being included in the v5.x release that's being finalized this week (with any luck.... I just have to document the CORS changes and migration guide).

Once this is live, I'll backport the types to v4.x as well - but that said, I'd recommend migrating on to v5, as it's adding a lot of power while allowing your own code to shrink further :)

[malobre]

Nice, thanks, v5 is looking great !

[kwhitley]

Heads up - v5 is out, and we have a guide on the additional args here: https://itty.dev/itty-router/typescript/additional-arguments

I still have some work to do with animated GIFs and such showing the typing in effect, but it should all be working now, across all 3 routers! :)

[kwhitley]

Ofc certainly re-open if v5 is still having issues :)

Once this is stable, I'll start working backwards to patch up 4.x as much as possible, start adding deprecation notices to things like router.handle, etc. :)