fix(platform-express) make check for existing middlewares work with Express 5 #14574
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…with Express 5 Express 5 made the router public API again and renamed the field from app._router to app.router. This broke the detection mechanism whether a middleware named "jsonParser" or "urlencodedParser" is already re or not, because app._router no longer exists.
Pull Request Test Coverage Report for Build 66d2d166-8df4-4956-b8ca-640d2ca9090cDetails
💛 - Coveralls |
|
LGTM |
2 tasks
|
I just realized that the fix is incomplete :( - I missed the first line of the condition, so basically my fix does not work at all right now... I will try to provide a PR tomorrow. Maybe some testing of the adapter should be added to help avoid regressions? I will try to figure out if I can add some basic test for the covered case, it that is desired/easily possible. @kamilmysliwiec you have an opinion regarding that? |
|
@luddwichr that would be great! |
luddwichr
added a commit
to luddwichr/nest
that referenced
this pull request
Feb 14, 2025
…Express 5 Express 5 made the router public API again and renamed the field from app._router to app.router. This broke the detection mechanism whether a middleware named "jsonParser" or "urlencodedParser" is already registered or not. Unfortunately, nestjs#14574 only fixed the issue partially. This commit now uses app.router everywhere. To avoid future regressions a test was added to verify the expected behavior.
12 tasks
luddwichr
added a commit
to luddwichr/nest
that referenced
this pull request
Feb 14, 2025
…Express 5 Express 5 made the router public API again and renamed the field from app._router to app.router. This broke the detection mechanism whether a middleware named "jsonParser" or "urlencodedParser" is already registered or not. Unfortunately, nestjs#14574 only fixed the issue partially. This commit now uses app.router everywhere. To avoid future regressions a test was added to verify the expected behavior.
|
@kamilmysliwiec I created #14640 with the fix and a new test. However, the pipeline failed for node > 18 and I have no clue why :( |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Express 5 made the router public API again and renamed the field from app._router to app.router. This broke the detection mechanism whether a middleware named "jsonParser" or "urlencodedParser" is already re or not, because app._router no longer exists.
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
The express adapter overwrites existing middlewares called jsonParser and urlencodedParser with its on parsers.
This regression was caused by updating from Express 4 to 5. Express 5 exposes the router via app.router, while Express 4 exposed it via app._router.
Issue Number: N/A - I didn't create an issue yet - let me know if you need that
What is the new behavior?
The express adapter respects existing middlewares called jsonParser and urlencodedParser and stops registering its own parser middleware.
Does this PR introduce a breaking change?
Other information