Route 'exclusive' option support

[paztis]

I'm trying petStore openapi contract to test this library over koa with your latest library

PetStore provide 2 routes
GET /pet/findPetByStatus
GET /pet/{id}

When I test the 1st one, I enter in the routers of 1 and 2
Of course validation crash because 'findPetByStatus' is not a valid id.
If the 1st declared one is valid, next ones must not be exec.

Do I miss something or is it a defect ?

[paztis]

Ok I found.
Koa router has a 'exclusive' option to support this.

Problem here is your createRouter is not allowing to pass down any option to the router création.

You may provide an option to passdown to new Router()

[mnahkies]

If that's the case it sounds a bug (tbh I thought it already accounted for this)

Reordering the routes in the openapi yaml should be a viable workaround in the meantime - it looks like it takes the order from the file.

[paztis]

Sorry I badly explain

petStore is an openapi reference (see here https://petstore3.swagger.io/)

Its definition of

GET /pet/findPetByStatus
GET /pet/{id}

is totally valid. /pet/findPetByStatus has the priority on /pet/{id}

In typescript-koa source code, in typescript-koa-router-builder.ts file
You have add the support of RouterOptions

export function ${createRouterExportName}(implementation: ${implementationExportName}, options: RouterOptions): KoaRouter {
  const router = new KoaRouter(options);

like this we use the exclusive option of KoaRouter (or any other option we want) to support this

createRouter(implementation, {exclusive: true})

[paztis]

I create a PR to support it
#438

[paztis]

any news ?

[mnahkies]

#438 doesn't actually solve the issue stated above (and doesn't include any test cases)

I've put together an e2e test in #442 that shows this is a valid bug, I think from reading issues in the @koa/router repository the answer is probably to stop calling next in the route handlers - but I need to confirm the implications of this (with some more e2e tests)

[paztis]

In @koa/router, currently the 'exclusive' option is allowing to exec only the last matching route. this one works well.

In my example it was only the 1st matching route to exec that is not supported for now.
I create a PR in @koa/router ton support it also

koajs/router#225

But in your code, the fact to allow the KoaRouter options at their creation will unlock it. It is the user that will or not enable the option. Like this you are fully backward compatible

[paztis]

If you're not calling the 'next', you will also break middlewares that are called after.
That's which the 'exclusive' option is différent. It acts at the vomputing of matching rules and not at the execution

[paztis]

I update my @koa/router PR with an official feature request: koajs/router#226
When this will be approved (I hope) we will have 2 solutions:

• let the KoaRouter options be settable by the end user (he will decide if there's no priority / priority first / prioriry last depending on its openApi)
• hardcode it to exclusive: 'first' (in this case we consider the openApi specification is always priorizing the 1st item

I found this old discussion (OAI/OpenAPI-Specification#2356) about specification and it is not really clear. I post on it to check

In petStore, there's was one specificity: the id was a number and not a string. It means the route /pet/findByStatus might not hit the id case

now if you want to not wait a @koa/router fix, and play with the next() call, we might broke middleware that do code after the response (logger, ...).

Perhaps it is possible for you to add something in the context to see if the route has already been catched and not to do anything inside (I mean not to exec you zod validation for example) ? Because here it was the zod validation that was crashing by saying the id is not an integer

I wait for your input before developing anything

[paztis]

Ok I review my copy base on one response
The openApi specification here https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#path-templating-matching clearly say the priority is from the less template based to the more one
So independentrly of its order, a route with no path params is prior to a route with 1 or more path param

I will upgrade my PR in @koa/router to fit to this
I keep you up to date about this

[paztis]

I recreate a new PR in @koa/router here koajs/router#227
Feature is descibed here koajs/router#226