Unexpected regression with middlewares since v6.4.6

[BobbyWibowo]

Continuation from discussion #110

There's actually an unexpected behavior that gets introduced since 6.4.6, and also persists in 6.4.7, that I did not previously notice when I claimed that 6.4.6 fixed the discussed issue

I confirmed it on a much simpler project so I didn't notice, whoops

Basically, when you have multiple middlewares initiated for multiple routes like the following example:

// Init separate rate limiter pools
server.use('/api/login', middlewareA)
server.use('/api/album/zip', middlewareB)
server.use('/api/tokens/change', middlewareC)
server.use('/api', middlewareD) // last as catch-all for any other /api/* paths

It appears that any requests to any /api/* paths (e.g. /api/albums), will end up matching all of the above, and will be triggered in sequence, according to order they were first initiated

And even requests to exact paths such as /api/login will have the exact same behavior (as in, it somehow triggers middlewares for /api/album/zip and /api/tokens/change as well)
It's supposed to only trigger /api/login and /api/ middlewares in sequence, before 6.4.6

[kartikk221]

So regarding the execution of the middlewares. They are executed in the following order:
1 - Global Middlewares in the order they were registered.
2 - Local Middlewares (Global but with with a certain path specification) in the order they were registered.
3 - Route-Specific Middlewares (Specified when creating the route itself) in the order they were specified.

With that in mind, is it correct to assume that the correct executions for a request to /api/login with the above middlewares should be the following?
1 - middlewareD()
2 - middlewareA()

[kartikk221]

I just pushed a commit 1821a4f which implements global ordering consistency to middlewares and also added tests for nested middlewares. See https://github.com/kartikk221/hyper-express/blob/master/tests/components/http/scenarios/middleware_execution_order.js as it is based upon your provided use case above but it doesn't seem to encounter the problem with all middlewares running on incorrect patterns.

If this commit resolves your issue above, then I can go ahead and push a minor update.
Feel free to pull the latest commit to your machine and run the tests with npm test.

[BobbyWibowo]

I went ahead and tried the tests in the repo but they also passed for me on my machine, lmao

But after doing a bit more testing, I finally pinpointed that the issue only occur to routes that are later registered with their own handlers (e.g. with server.<any>() or via HyperExpress.Router)

Assume the following sample codes in https://github.com/BobbyWibowo/hyper-express-playground/blob/77083a4a1ad606f17e4a34c1aed85c9233af2214/tests/middlewares_order.js (tldr; register various local middlewares, but add a GET handler for /api/login as well afterwards)

/api/register did not have a handler, so not_found_handler caught it, and as can be seen, it indeed triggered the correct middlewares,
but not the case for /api/login which has a GET handler

[kartikk221]

Could you try again with the latest commit I made? I get the following results with your middlewares_order.js on my device with the latest commit: https://gyazo.com/9c6b2bb448a1cd928ddb72f1a9f37dd3 (I tested from the browser).

[BobbyWibowo]

Can confirm latest commit works as expected on my main project now 👍

[kartikk221]

@BobbyWibowo This change has been pushed in the recent v6.4.8 update.