Are paramter format options no longer supported?

[egloffmark]

In previous older versions of path-to-regexp you could apply regexp format rules for parameters like '/:lang(\w{2})' it seems that this is no longer supported? If it is still supported can you please provide an example how this can be used? If it is not supported, any plans to bring this feature back? If not which is the version which still supports this feature and is mot backward compatible with v2.4.0? Thank you

import { Keys, pathToRegexp } from "path-to-regexp";

const path = '/:lang(\\w{2})'
const { regexp, keys } = pathToRegexp(path);

Error: Uncaught (in promise) TypeError: Unexpected ( at 6, expected END: https://git.new/pathToRegexpError

[blakeembrey]

No, it is not supported. I would like to add it back, but it needs to be done in a safe way that can avoid backtracking. Any old version has it, but the comments here might help you decide which version to migrate from v2: #332 (comment)

[dcharbonnier]

The fact that this library, which is indirectly used by NestJS, removes a lot of functionality is a significant issue for many users.

For instance, if I want to support the route /:lang(de|en)?/my-route, there's no longer a way to do so. I could define separate routes like [/de/my-route, /en/my-route], but that would mean losing the lang parameter. Alternatively, I could use {/:lang}/my-route and manually check the value of lang to return a 404, but at that point, I might as well discard the router entirely and implement my own.

I understand the concerns about DDoS attacks, but removing these functionalities isn't the right solution to a security issue. A better approach would be to introduce an option like allowUnsafeRegexp, giving users the choice to enable or disable such behavior.

[blakeembrey]

While I don’t disagree with you, it was decided that it would lead to more CVEs that are unpatchable down that route. Instead of writing your own router, why not attempt a PR adding the feature back in a safe way?

[dcharbonnier]

The issue is that now the route syntax changed. Every library is fighting to fix the issue created by this change, not sure this can be reversed now. And as this change is not compatible with other routers syntax, this is even worse for frameworks using different adapters like nestjs

[dcharbonnier]

pragmaticivan/nestjs-otel#521

[dcharbonnier]

nestjs/nest#14545