PR here #4787
Is your feature request related to a problem? Please describe.
Use own interface for Socket request to allow extending the request interface with custom properties without polluting the IncomingMessage type which is also used by Express/Passport.
Using socket.io with passport middlewares causes issues when using the same 'userProperty' key is used for both - for example by extending IncomingMessage { user: Express.User } we break passport's isAuthenticated() function, because now typescript thinks that the request is always of the type AuthenticatedRequest as IncomingMessage always has a user property on itself. To fix this, I believe we should be able to extend only the request type inside socket.io -> SocketRequest.
Describe the solution you'd like
Use own interface for Socket request to allow extending the request interface independently of Express.
Describe alternatives you've considered
I haven't found any reasonable workarounds.
Additional context
See #4787
PR here #4787
Is your feature request related to a problem? Please describe.
Use own interface for Socket request to allow extending the request interface with custom properties without polluting the IncomingMessage type which is also used by Express/Passport.
Using socket.io with passport middlewares causes issues when using the same 'userProperty' key is used for both - for example by extending IncomingMessage { user: Express.User } we break passport's isAuthenticated() function, because now typescript thinks that the request is always of the type AuthenticatedRequest as IncomingMessage always has a user property on itself. To fix this, I believe we should be able to extend only the request type inside socket.io -> SocketRequest.
Describe the solution you'd like
Use own interface for Socket request to allow extending the request interface independently of Express.
Describe alternatives you've considered
I haven't found any reasonable workarounds.
Additional context
See #4787