add template for wrapping data-fetching functions

Author: lobsterkatie

packages/nextjs/rollup.npm.config.js

@@ -14,18 +14,23 @@ export default [
   ),
   ...makeNPMConfigVariants(
     makeBaseNPMConfig({
-      entrypoints: ['src/config/templates/prefixLoaderTemplate.ts'],
+      entrypoints: [
+        'src/config/templates/prefixLoaderTemplate.ts',
+        'src/config/templates/dataFetchersLoaderTemplate.ts',
+      ],
 
       packageSpecificConfig: {
         output: {
-          // preserve the original file structure (i.e., so that everything is still relative to `src`)
+          // Preserve the original file structure (i.e., so that everything is still relative to `src`). (Not entirely
+          // clear why this is necessary here and not for other entrypoints in this file.)
           entryFileNames: 'config/templates/[name].js',
 
           // this is going to be add-on code, so it doesn't need the trappings of a full module (and in fact actively
           // shouldn't have them, lest they muck with the module to which we're adding it)
           sourcemap: false,
           esModule: false,
         },
+        external: ['@sentry/nextjs'],
       },
     }),
   ),

packages/nextjs/src/config/templates/dataFetchersLoaderTemplate.ts

@@ -0,0 +1,27 @@
+import type {
+  GetServerSideProps as GetServerSidePropsFunction,
+  GetStaticPaths as GetStaticPathsFunction,
+  GetStaticProps as GetStaticPropsFunction,
+} from 'next';
+
+declare const _getServerSideProps: GetServerSidePropsFunction;
+declare const _getStaticProps: GetStaticPropsFunction;
+declare const _getStaticPaths: GetStaticPathsFunction;
+
+// We import the SDK under a purposefully clunky name, to lessen to near zero the chances of a name collision in case
+// the user has also imported Sentry for some reason. (In the future, we could check for such a collision using the AST,
+// but this is a lot simpler.)
+//
+// TODO: This import line is here because it needs to be in the injected code, but it also would (ideally)
+// let us take advantage of typechecking, via the linter (both eslint and the TS linter), using intellisense, and when
+// building. Solving for all five simultaneously seems to be tricky, however, because of the circular dependency. This
+// is one of a number of possible compromise options, which seems to hit everything except eslint linting and
+// typechecking via `tsc`. (TS linting and intellisense both work, though, so we do get at least some type safety.) See
+// https://github.com/getsentry/sentry-javascript/pull/5503#discussion_r936827996 for more details.
+//
+// eslint-disable-next-line import/no-extraneous-dependencies, import/no-unresolved
+import * as ServerSideSentryNextjsSDK from '@sentry/nextjs';
+
+export const getServerSideProps = ServerSideSentryNextjsSDK.withSentryGSSP(_getServerSideProps);
+export const getStaticProps = ServerSideSentryNextjsSDK.withSentryGSProps(_getStaticProps);
+export const getStaticPaths = ServerSideSentryNextjsSDK.withSentryGSPaths(_getStaticPaths);

packages/nextjs/tsconfig.types.json

@@ -1,6 +1,8 @@
 {
   "extends": "./tsconfig.json",
 
+  "exclude": ["src/config/templates/*"],
+
   "compilerOptions": {
     "declaration": true,
     "declarationMap": true,