5.x - undocumented wildcard behaviour change in req.params #2090
Description
Description
Anthony Moulen pointed out on Slack a change in req.params behaviour when using wildcards. Since path-to-regexp@7 wildcards split the matched path on /.
| route 4.x | route 5.x | request path | req.params 4.x |
req.params 5.x |
|---|---|---|---|---|
'/:name' |
'/:name' |
/a%2fb |
{ name: 'a/b' } |
{ name: 'a/b' } |
'/*' |
'/*name' |
/ |
{ '0': '' } |
not matched |
'/*' |
'/{*name}' |
/ |
{ '0': '' } |
{} |
'/*' |
'/*name' |
/a%2fb/c |
{ '0': 'a/b/c' } |
{ name: [ 'a/b', 'c' ] } |
'/*' |
'/*name' |
/a%2fb |
{ '0': 'a/b' } |
{ name: [ 'a/b' ] } |
The migration guide describes the changes in path matching - that wildcard parameters now must be named and that {} is required to make the path segment optional. What it does not described is that:
- Wildcard parameters in
req.paramsare always represented as arrays of decoded segments, not a single string. - (less important) Optional wildcard segment that is not matched does not exist in
req.params, while in 4.x it was an empty string. - (not important)
req.paramsobject in 5.x has null prototype.
Expectations
Migration guide should mention different req.params behaviour with regard to wildcard parameters.
This probably can be combined with req.params documentation improvements requested in #1891.