Extending request while using a custom server/standalone mode

[balazsorban44]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Versions of Next.js 13.4.13 and above are affected.

Which area(s) of Next.js are affected? (leave empty if unsure)

Data fetching (gS(S)P, getInitialProps), Routing (next/router, next/navigation, next/link), Standalone mode (output: "standalone")

Link to the code that reproduces this issue or a replay of the bug

Reproductions are available in the linked issues below

To Reproduce

Reproductions are available in the linked issues below

Describe the Bug

When using a custom server/standalone mode, there might be an incentive to extend the request that is then passed on to other parts of the application to access the extra property.

Since 13.4.13, this is not straightforward/possible.

Link to related issues to consolidate them in a single location for tracking:

• Regression in ctx.req parameters availability in Document getInitialProps in version 13.4.13 (works in 13.4.12) #53883
• Extending request object stopped working #54288
• Extra fields attached to request no longer readable in API handler #54129
• Global variable in custom server since 13.4.13 #54435
• Data inside the res.locals object from express in custom server is not available in pages/ after version 13.4.13+ #54381

Expected Behavior

This is a bit tricky to solve because of the render workers, but we would like to track this until we have an answer/solution.

NOTE

If you are affected, please leave a comment below with your use case and a reproduction of the issue (make it as minimal as possible, so it's easy to investigate to anyone without prior knowledge of your codebase). Please do not comment without meaningful additional information (if you want to comment "same", etc., react 👍 to the original description instead)! Thank you.

Unhelpful/unrelated comments will be marked as off-topic/spam to keep the readability of the thread.

_NEXT-1553

[coltonehrman]

I found some interesting stuff regarding the issues in 13.4.13

Initial PR
#52492

Reverted before 13.4.12 release
#53016

Reverted Revert
#53029

No trace of when or where the reverted revert got released
It's as if this change got snuck in to 13.4.13

My hunch is this is what "broke the world", separating the router & render processes basically broke all things being passed between custom server (runs before routing) and render (runs in Next.js)

[coltonehrman]

Tracing logic:

invokeRequest get's called:
https://github.com/vercel/next.js/blob/canary/packages/next/src/server/lib/router-server.ts#L378-L386

fetch get's called:
https://github.com/vercel/next.js/blob/canary/packages/next/src/server/lib/server-ipc/invoke-request.ts#L22-L41

Not sure how this worked before, but based on this logic, the extended res or req object will NEVER get sent to the "render" as it is making a new http request internally. This design of "separation" inherently will not support passing data between the custom server and Next.js router/renderer.

[coltonehrman]

No trace of when or where the reverted revert got released
It's as if this change got snuck in to 13.4.13

The reverted revert was the first commit in v13.4.13-canary.0.

Yeah, it appears so. They should update the release notes here https://github.com/vercel/next.js/releases/tag/v13.4.13-canary.0 and here https://github.com/vercel/next.js/releases/tag/v13.4.13

This is arguably the BIGGEST change of the whole release and likely should have been a major/minor update. Not patch.

[grawk]

Hey maintainers. This is a radical departure in terms of functionality for teams using Next.js with an express custom server, and relying upon decorated req/res objects. Can you all please provide a statement soon about whether this loss of functionality was purposeful and will not be maintained going forward? It is critical to helping with my team's decision of whether to continue using Next.js for our use case.

[nicholasgriffintn]

It is critical to helping with my team's decision of whether to continue using Next.js for our use case.

^ agreed, and I'd add, it seems that related functionality for custom server isn't being tested or validated, or considered for breaking changes, it would be good if it was.

If it's stated that next doesn't support custom server then that is also fine though.

[timneutkens]

This is a bug. We're figuring out how to bring this back as it's non-trivial to support the request object being modified, it's accidental that it broke, there was no test for that, the tests for using the custom server API test the documented behavior which is passing Node.js request / response into the handler.

[coltonehrman]

This is a bug. We're figuring out how to bring this back as it's non-trivial to support the request object being modified, it's accidental that it broke, there was no test for that, the tests for using the custom server API test the documented behavior which is passing Node.js request / response into the handler.

Will the bug fix only fix the req/res extension use case?

Based on the new code & design, this is just one case that is broken, other cases would include any bootstrapping of global objects at the custom server level & singleton modules that get required and depended on in the custom server and within Next.js contexts.

[coltonehrman]

This is a bug. We're figuring out how to bring this back as it's non-trivial to support the request object being modified, it's accidental that it broke, there was no test for that, the tests for using the custom server API test the documented behavior which is passing Node.js request / response into the handler.

Will the bug fix only fix the req/res extension use case?

Based on the new code & design, this is just one case that is broken, other cases would include any bootstrapping of global objects at the custom server level & singleton modules that get required and depended on in the custom server and within Next.js contexts.

I have opened a new issue related to the other bugs #54782

[cosieLq]

Another change that's happened in #53029
is that the internal routing for static assets (/_next/static).

As mentioned in #54159 , custom response headers in next config are not applied to static assets when i18n is configured.
Since v13.4.13, NextJs also shows this inconsistency in applying custom headers for static assets between with and without i18n.

I hope this issue will be fixed soon as well. It has become a blocker for us.

[shaunwarman]

This is a bug. We're figuring out how to bring this back as it's non-trivial to support the request object being modified, it's accidental that it broke, there was no test for that, the tests for using the custom server API test the documented behavior which is passing Node.js request / response into the handler.

@timneutkens would you mind sharing what specific change was made here to get eyes / brainstorming?

[nicholasgriffintn]

Just tried it out real quick, getting an error NextRouter was not mounted on our app using pages with 13.4.20-canary.24, not getting it with 13.4.20-canary.23.

[nicholasgriffintn]

^ Update: Changing useRouter imports in the packages that were erroring to use next/compat/router seems to have sorted the issue, it seems the change made means that next/router imports no longer work from packages for some reason.

[github-actions]

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.