How to debug / troubleshoot itty-router?

[danbars]

Is there anything that I can log to:

1. Better understand which routes were matched by the router?
2. See the regular expressions that were created for each route so I can manually test them against a given URI?

I have a route that seem to be not-mathced for no apparent reason, and I'm not sure how to debug this.
I've seen some threads that mentioned:

const options = {}
const router = Router(options)
...
console.log(options)

This didn't work though... Options came out {}

Another thing that I've tried:

 async fetch(request, env, ctx) {
    router.routes.forEach(r => console.log(JSON.stringify(r)))
    return router.handle
}

This printed:

["ALL",{},[null]]
["OPTIONS",{},[null]]
["POST",{},[null]]
["POST",{},[null]]
["ALL",{},[null]]

so I still didn't get any hint on the inners of the router...

Any idea?

[kwhitley]

Sure!

Actually you're just seeing a product of how things are JSON serialized... RegExp becomes {} and a function (e.g. any route handler/middleware) becomes null.

To view the regex, you'll actually need to explicitly call a .toString() on that second param. You could do the same on each route handler, but I don't know how much that would help you.

So to see your routes more effectively, I might try the following:

const routes = router.routes.map(([method, regex]) => [method, regex.toString()])

console.log(JSON.stringify(routes))

That'll at least show you the human-readable regex to see where the disconnect is. :) I'm also happy to discuss your actual code on Discord (or Zoom) if you're still stuck!

[danbars]

Awesome, @kwhitley , thanks for the quick response!
I think it'd be helpful to have this in the readme.
Happy to PR if you want.

[kwhitley]

Great suggestion! I'd certainly love a PR for the addition, and I'll make sure it finds a home in the upcoming v4.x docs as well (https://itty.dev/itty-router)... of course you're welcome to submit a request for updating those docs too! :)

[kwhitley]

@danbars - as of v4.x, you can actually check request.route to find the route that matched. It will be a string like:

/v1/items/:id? or whatever you defined in your path (it will prepend the base as well). This was introduced as a way for route handlers to actually determine/broadcast their own match requirements (useful in creating self-documenting APIs).

Hope that helps a bit as well!

// assumes v4.x

router.get('/foo/:bar/:baz?', ({ route }) => route) // '/foo/:bar/:baz?'