Support Express-like frameworks
Opened this issue · 4 comments
E.g. tinyhttp. The main issue is the use of Express-specific type declarations for Request, Response.
Typically you would wrap the middleware and then pass in what it needs, but I can see how the TypeScript type declarations would get in the way of that. Because you aren't using express, yet suddenly you have to pass in an express based Request.
I'll try setting up my own small tinyhttp TS project and see what I can do.
I suspect this can be resolved by allowing for a generic type which defaults to the express Request one, unioned with the bare minimum properties expected on the req object, similarly for Response.
The one concern there is the res.cookie method provided by cookie-parser, which csrf-csrf is dependent on.
I could go the way of express-session, which removed cookie-parser as a dependency and instead handled setting the cookie itself. But I think that would need to go into v4.
As a stop-gap measure I set up otterjs/csrf-csrf - thankyou for looking into this :)
Ah yep.
Thinking on this, it might definitely be best to set the cookie using methods that don't depend on a framework specific dependency similar to how express-session handles it. Instead of depending on cookie-parser, express session uses the dependencies that cookie-parser uses to encode and set the cookie into the header without losing other Set-Cookie header information, and I believe that approach is framework agnostic.
Making the types less express specific would definitely be handy too.
One strategy I've been using to make request/response types less framework specific can be seen here:
https://github.com/OtterJS/otterhttp/blob/main/packages/response/src/types.ts
The request type 'snippets' can be composed as needed - e.g. one function only requires HasOutgoingHeaders, another might require HasOutgoingHeaders & HasReq<HasIncomingHeaders>
That example Picks from one of my own types, but you get the gist - can be easily replaced with Pick<http.ServerResponse, ...>