|
1 | | -## [0.14.0] - 2025-02-03 |
| 1 | +## [0.14.0] - 2025-02-04 |
2 | 2 |
|
3 | 3 | ## Changed |
4 | 4 |
|
5 | | -- multiple paths can now be registered on the same HTTP verb, and if the |
6 | | - "static" and the "parameter" portions of the registered paths somehow overlap, |
7 | | - then the handler is invoked **once for each registered path**; for example if |
8 | | - we register `@Get("/foo/:bar")` and `@Get("/foo/bar")` (in that order) on the |
9 | | - same handler function, then for every request to `/foo/bar`, the same handler |
10 | | - is invoked **twice**, the first time having no "param" at all, and the 2nd |
11 | | - time having the param `bar` with the value `"bar"`. This behavior follows TC39 |
12 | | - decorator specs where all decorators to a function are applied "from inside |
13 | | - out" aka: the last declared decorator gets applied first, and so on |
| 5 | +- multiple paths can now be registered on the same HTTP verb, and if the paths |
| 6 | + are exactly the same, or if the "static" and the "parameter" portions of the |
| 7 | + paths somehow overlap, then the handler is invoked **once for each registered |
| 8 | + path**; for example if we register `@Get("/foo/:bar")` and `@Get("/foo/bar")` |
| 9 | + (in that order) on the same handler function, then for every request to |
| 10 | + `/foo/bar`, that handler is invoked **twice**, the first time having no |
| 11 | + "param" at all, and the 2nd time having the param `bar` with the value |
| 12 | + `"bar"`. This behavior follows TC39 decorator specs where all decorators to a |
| 13 | + function are applied "from inside out" aka: the last declared decorator gets |
| 14 | + applied first, and so on |
14 | 15 |
|
15 | 16 | ## Added |
16 | 17 |
|
|
0 commit comments