-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support custom Request types #189
Comments
When did Next.js make this change? I think it would be better to approach them and see if it could be relaxed somehow. Making it pluggable would be impossible as there is specific behavior that is needed - and it's not possible to bolt it on top of another prototype. This library does not use IncomingMessage because it'd be very hard to do so. It's not impossible, so you might give that a try. |
@mcollina in https://github.com/vercel/next.js/releases/tag/v12.0.9. Specifically in this commit. The issue is that before they simply set the TypeScript request type to |
Prerequisites
馃殌 Feature Proposal
Support for the
request
object (instance of theRequest
(lib/request.js
) class) to inherit from a custom class besidesstream.Readable
.Motivation
Starting from v12.0.9, next.js validates the request object's type is an
http.IncomingMessage
instance. If it's not, no error is thrown but the request will fail due to an internal type conversion not being made.This is an issue for using
light-my-request
to test API requests that usenext.js
. Specifically, this is currently blocking bumpingnext.js
' version in fastify-nextjs (fastify/fastify-nextjs#514) because tests don't pass with the current structure oflight-my-request
.Example
Supporting a new
options
flag, namelycustomRequestType
and adding the following snippet inlib/request.js:124
(Request
function definition) should do the trick:The text was updated successfully, but these errors were encountered: