fix(nextjs): Make NextApiHandler type version-agnostic

[lobsterkatie]

In withSentry in the nextjs SDK, we import and use the NextApiHandler type provided by Next. In vercel/next.js#35166, which was released in 12.1.6, that type switched to using uknown rather than void for the function's return type.

For users this isn't a problem. If they import both the type from Nextjs and withSentry from our SDK (which in turn imports the type), both imports will be pointed at their local version of Next, and the types will match. For us, though, it's a different story. Our dev version of Next is the lowest one the SDK supports, 10.0.8. If we link our SDK into a test app, the NextApiHandler we're importing will be coming from the node_modules in our repo, whereas the test app will be pulling the type from its own node_modules. And that works just fine... until you try to upgrade your test app to Next 12.1.6 or higher, at which point your app starts refusing to build because of the mismatch.

(See #5737 (comment) for a more detailed explanation of the above.)

Though at first it might seem that the obvious solution is just to update our dev version of Next to 12.1.6+, if we do that we'll just be back in the same place with the same problem trying to use lower versions of Next in our test apps. Thus we need the type to work for both older and newer versions, which is what this PR does.

[github-actions]

size-limit report 📦

Path	Size
@sentry/browser - ES5 CDN Bundle (gzipped + minified)	19.53 KB (+0.02% 🔺)
@sentry/browser - ES5 CDN Bundle (minified)	60.31 KB (0%)
@sentry/browser - ES6 CDN Bundle (gzipped + minified)	18.12 KB (0%)
@sentry/browser - ES6 CDN Bundle (minified)	53.23 KB (0%)
@sentry/browser - Webpack (gzipped + minified)	19.91 KB (0%)
@sentry/browser - Webpack (minified)	64.61 KB (0%)
@sentry/react - Webpack (gzipped + minified)	19.93 KB (0%)
@sentry/nextjs Client - Webpack (gzipped + minified)	44.97 KB (0%)
@sentry/browser + @sentry/tracing - ES5 CDN Bundle (gzipped + minified)	26.1 KB (+0.01% 🔺)
@sentry/browser + @sentry/tracing - ES6 CDN Bundle (gzipped + minified)	24.48 KB (+0.01% 🔺)

[lforst]

Btw, do you know are there issues related to this we can close now?

[lobsterkatie]

Btw, do you know are there issues related to this we can close now?

Not unless one of us has filed an issue about not being able to build a test app with Next 12.1.6+ while having a local copy of SDK linked in, which... I'll go look, but it'd surprise me.

[lforst]

but it'd surprise me

Oh I thought since the type we allow in withSentry is now broader we enable people on various versions but I guess that's not the case (?).

Also quickly looked for issues but didn't find anything. 👍

[lobsterkatie]

Oh I thought since the type we allow in withSentry is now broader we enable people on various versions but I guess that's not the case (?).

So, the issue is API page code like this:

import { NextApiHandler } from 'next';
import { withSentry } from '@sentry/nextjs';

const handler: NextApiHandler = ...

export default withSentry(handler);

withSentry will only accept (its idea of) a NextApiHandler as input. handler is (the test app's idea of) a NextApiHandler. So far, so good.

Scenario 1: User app

• @sentry/nextjs and next are installed in user app's node_modules
• @sentry/nextjs from user's node_modules looks for next in its own node_modules, but deps are hoisted, so it ends up finding user-installed copy, and it uses whatever version of the type it finds
• User page also looks for next in user's node_modules, finds the same copy @sentry/nextjs found, and uses that same version of the type

Scenario 2: SDK dev test app before this change

• @sentry/nextjs is linked from local repo into project, next is installed in project
• @sentry/nextjs from local repo looks for next in local repo's node_modules, finds 10.0.8, and uses type based on void
• User page looks for next in user's node_modules, finds whatever version it finds, and uses type based on either void or unknown, depending on next version. In the former case, fine, but in the latter case, build errors ensue.

Scenario 3: SDK dev test app after this change

• @sentry/nextjs is linked from local repo into project, next is installed in project
• @sentry/nextjs from local repo uses hard-coded type based on both void and unknown
• User page looks for next in user's node_modules, finds whatever version it finds, and uses type based on either void or unknown, depending on next version. Either way, it matches the SDK type, so no build errors.

Does that make sense?

[lforst]

Ah right. That makes a lot of sense. Thanks for the detailed explanation and also thanks for updating that comment!