Releases: Bessonov/node-http-router
v2.3.0 2022-08-28
v2.2.0 2022-08-21
Reintroduce default handler from pre-v2 again. Actually, this option is optional and not documented, because in this state it's a workaround to more general concept which can be called "ordering of matchers". It allows putting a very last matcher being at the top of router creation.
Currently, I have no idea (and TBH I didn't spend time on it) how to do it the right way. Despite there are many options like adding an attribute or a global sorter function, none of them feels like a solution. Because of that, use this option only if you migrate from pre-v2. I'm pretty sure the option will be removed again.
What's Changed
v2.1.0 2022-08-10
v2.0.0 2022-06-24
I am proud to present the new release with new features! While the core concept is still the same, there are big changes on boundaries.
First of all, the router isn't tied to node or http anymore! Although the primary use case is still node's request routing, you can use it for use cases like event processing now. See the example in README.md
.
For that reason the mandatory 404 route inside the Router
's constructor was removed. Furthermore, built-in matchers are now contract based and don't expect concrete IncomingMessage
and ServerResponse
instances.
Another big feature is the support of nested routers. This is useful for example for modularization or removing url prefix in a multi-tenant SaaS application.
Breaking changes / migration
// before
const router = new Router((req, res) => send(res, 404))
// after
const router = new NodeHttpRouter()
router.addRoute({
matcher: new BooleanMatcher(true),
handler: ({ data: { res } }) => send(res, 404),
})
// before
handler: middlewares(async function myApi(req, res, {
token,
}) {
// after
handler: middlewares(async function myApi({
data: {
req, res, token,
},
}) {
// before
new ExactQueryMatcher({
response_type: 'code',
// after
new ExactQueryMatcher({
response_type: ['code'] as const,