Closed ljosberinn closed 4 years ago
For now, I've added these proxy types:
import { NextApiResponse, NextApiRequest } from 'next';
import {
RequestHandler as NextConnectRequestHandler,
Middleware as NextConnectMiddleware,
} from 'next-connect';
export type Middleware<T = {}, S = {}> = NextConnectMiddleware<
NextApiRequest & T,
NextApiResponse & S
>;
export type RequestHandler<T = {}, S = {}> = NextConnectRequestHandler<
NextApiRequest & T,
NextApiResponse & S
>;
and use them like this:
const loginHandler: RequestHandler = async (req, res, next) => {}
export default nextConnect().post(loginHandler);
In fact, I prefer this approach but it should imo be documented :)
I'm certainly sorry. it was really irresponsible for me to do a breaking change in a minor. Some people seem to use next-connect
with getServerSideProps
and others in normal pages, which have only Node IncomingMessage
and ServerResponse
as req
and res
.
I'm wondering what is the best way to support both API Routes and that.
Hey,
wanted to ask why the signature changed? Now most of my code is failing because
res.json()
does not exist onServerResponse
. Given that's still the recommended way of usage in the docs...res.send
doesnt exist either.I can circumvent it with generics, but is this intended?