Skip to content

Commit 1058caf

Browse files
committed
make handler type version-agnostic
1 parent ff4f97f commit 1058caf

File tree

1 file changed

+20
-5
lines changed

1 file changed

+20
-5
lines changed

packages/nextjs/src/utils/withSentry.ts

Lines changed: 20 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -10,11 +10,26 @@ import {
1010
stripUrlQueryAndFragment,
1111
} from '@sentry/utils';
1212
import * as domain from 'domain';
13-
import { NextApiHandler, NextApiRequest, NextApiResponse } from 'next';
14-
15-
// This is the same as the `NextApiHandler` type, except instead of having a return type of `void | Promise<void>`, it's
16-
// only `Promise<void>`, because wrapped handlers are always async
17-
export type WrappedNextApiHandler = (req: NextApiRequest, res: NextApiResponse) => Promise<void>;
13+
import { NextApiRequest, NextApiResponse } from 'next';
14+
15+
// These are the same as the official `NextApiHandler` type, except
16+
//
17+
// a) The wrapped version returns only promises, because wrapped handlers are always async.
18+
//
19+
// b) Instead of having a return types based on `void` (Next < 12.1.6) or `unknown` (Next 12.1.6+), both the wrapped and
20+
// unwrapped versions of the type have both. This doesn't matter to users, because they exist solely on one side of that
21+
// version divide or the other. For us, though, it's entirely possible to have one version of Next installed in our
22+
// local repo (as a dev dependency) and have another Next version installed in a test app which also has the local SDK
23+
// linked in.
24+
//
25+
// In that case, if those two versions are on either side of the 12.1.6 divide, importing the official `NextApiHandler`
26+
// type here would break the test app's build, because it would set up a situation in which the linked SDK's
27+
// `withSentry` would refer to one version of the type (from the local repo's `node_modules`) while any typed handler in
28+
// the test app would refer to the other version of the type (from the test app's `node_modules`). By using a custom
29+
// version of the type compatible with both the old and new official versions, we can use any Next version we want in
30+
// a test app without worrying about type errors.
31+
type NextApiHandler = (req: NextApiRequest, res: NextApiResponse) => void | Promise<void> | unknown | Promise<unknown>;
32+
type WrappedNextApiHandler = (req: NextApiRequest, res: NextApiResponse) => Promise<void> | Promise<unknown>;
1833

1934
export type AugmentedNextApiResponse = NextApiResponse & {
2035
__sentryTransaction?: Transaction;

0 commit comments

Comments
 (0)