Non-root generic middlewares will not trigger if it does not explicitly contain routes

[BobbyWibowo]

Suppose the following codes:

// const express = require('express')
const HyperExpress = require('hyper-express')

console.log('Starting\u2026')
// const server = express()
const server = new HyperExpress.Server({
  fast_abort: true
})

server.use((req, res, next) => {
  console.log('root middleware')
  next()
})

server.use('/swagger', (req, res, next) => {
  console.log('/swagger middleware')
  next()
})

server.set_not_found_handler((req, res) => {
  console.log('not_found_handler')
  res.status(404).end()
})

server.set_error_handler((req, res) => {
  console.log('error_handler')
  res.status(500).end()
})

;(async () => {
  const port = process.env.PORT || 3001
  await server.listen(port)
  console.log(`Started on port ${port}`)
})()

When you do GET /swagger/anything, hyper-express will only trigger the root middleware

This means you cannot have a generic middleware on non-root routes designed to selectively handle requests within non-root routes
For example, serve-static-alike middleware

You could add:

server.any('/swagger/*', (req, res) => {})

Which will then allow the swagger middleware to trigger properly, but that's more of a workaround than anything

You will still have to programmatically call your not_found_handler directly if your middleware can't handle the request due to not found file and such (i.e. can't just do next()), since that any() handler will simply continue to handle the request instead

---

On another note, you indeed can just do the following in ExpressJS

server.use('/non-root-path', express.static(path))

Because following the code example above, swagger middleware will simply trigger properly when doing GET /swagger/anything

[kartikk221]

Great find, this makes total sense as Routes are ones that contain and execute middlewares thus If no actual routes exist for a specific range of pattern, then those middlewares will never run. I'll add a fix for this to improve this behavior in the next update.

[kartikk221]

So essentially Express will modify the Request.path to reflect it's local path to the middleware's globalp path instead of the
server root global request path?

[BobbyWibowo]

Apparently so, yeah

In the context of serve-static-alike middleware, that behavior makes the middleware just work, regardless of the actual path it's being initiated on, so I guess that makes sense

I cannot say if matching that behavior is fine for every other scenarios however
At least for my own use case it'll only bring benefits

[kartikk221]

Changing the behavior of Request.path would certainly be a breaking change for any existing implementations people may have on HyperExpress. So I'll add it to the roadmap to be implemented in the next major switch.

[BobbyWibowo]

Sounds good to me
At least 6.4.6 no longer require the server.any()-thingy workaround, and the cons that come with doing so, which is already pretty good imho

[kartikk221]

Sounds good to me At least 6.4.6 no longer require the server.any()-thingy workaround, and the cons that come with doing so, which is already pretty good imho

Yeah, I was too focused on performance and would essentially match all registered middlewares to all registered routes based on path. Never occured to me that wildcard routes can receive requests to any set of paths hence per-request path pattern matching would have to be done to cover 100% of requests with middlewares.