Move wrapping function into loader

Author: Luca Forstner

packages/nextjs/src/config/loaders/proxyLoader.ts

@@ -1,10 +1,15 @@
+import commonjs from '@rollup/plugin-commonjs';
+import virtual from '@rollup/plugin-virtual';
 import { stringMatchesSomePattern } from '@sentry/utils';
 import * as fs from 'fs';
 import * as path from 'path';
+import { rollup } from 'rollup';
 
-import { rollupize } from './rollup';
 import { LoaderThis } from './types';
 
+const SENTRY_WRAPPER_MODULE_NAME = 'sentry-wrapper-module';
+const WRAPPING_TARGET_MODULE_NAME = '__SENTRY_WRAPEE__.cjs';
+
 type LoaderOptions = {
   pagesDir: string;
   pageExtensionRegex: string;
@@ -57,7 +62,7 @@ export default async function proxyLoader(this: LoaderThis<LoaderOptions>, userC
   // Run the proxy module code through Rollup, in order to split the `export * from '<wrapped file>'` out into
   // individual exports (which nextjs seems to require).
   try {
-    return await rollupize(templateCode, userCode);
+    return await wrapUserCode(templateCode, userCode);
   } catch (err) {
     // eslint-disable-next-line no-console
     console.warn(
@@ -66,3 +71,81 @@ export default async function proxyLoader(this: LoaderThis<LoaderOptions>, userC
     return userCode;
   }
 }
+
+/**
+ * Use Rollup to process the proxy module code, in order to split its `export * from '<wrapped file>'` call into
+ * individual exports (which nextjs seems to need).
+ *
+ * Wraps provided user code (located under the import defined via WRAPPING_TARGET_MODULE_NAME) with provided wrapper
+ * code. Under the hood, this function uses rollup to bundle the modules together. Rollup is convenient for us because
+ * it turns `export * from '<wrapped file>'` (which Next.js doesn't allow) into individual named exports.
+ *
+ * Note: This function may throw in case something goes wrong while bundling.
+ *
+ * @param wrapperCode The wrapper module code
+ * @param userModuleCode The user module code
+ * @returns The wrapped user code
+ */
+async function wrapUserCode(wrapperCode: string, userModuleCode: string): Promise<string> {
+  const rollupBuild = await rollup({
+    input: SENTRY_WRAPPER_MODULE_NAME,
+
+    plugins: [
+      // We're using virtual modules so we don't have to mess around with file paths
+      virtual({
+        [SENTRY_WRAPPER_MODULE_NAME]: wrapperCode,
+        [WRAPPING_TARGET_MODULE_NAME]: userModuleCode,
+      }),
+
+      // People may use `module.exports` in their API routes or page files. Next.js allows that and we also need to
+      // handle that correctly so we let a plugin to take care of bundling cjs exports for us.
+      commonjs(),
+    ],
+
+    // We only want to bundle our wrapper module and the wrappee module into one, so we mark everything else as external.
+    external: source => source !== SENTRY_WRAPPER_MODULE_NAME && source !== WRAPPING_TARGET_MODULE_NAME,
+
+    // Prevent rollup from stressing out about TS's use of global `this` when polyfilling await. (TS will polyfill if the
+    // user's tsconfig `target` is set to anything before `es2017`. See https://stackoverflow.com/a/72822340 and
+    // https://stackoverflow.com/a/60347490.)
+    context: 'this',
+
+    // Rollup's path-resolution logic when handling re-exports can go wrong when wrapping pages which aren't at the root
+    // level of the `pages` directory. This may be a bug, as it doesn't match the behavior described in the docs, but what
+    // seems to happen is this:
+    //
+    //   - We try to wrap `pages/xyz/userPage.js`, which contains `export { helperFunc } from '../../utils/helper'`
+    //   - Rollup converts '../../utils/helper' into an absolute path
+    //   - We mark the helper module as external
+    //   - Rollup then converts it back to a relative path, but relative to `pages/` rather than `pages/xyz/`. (This is
+    //     the part which doesn't match the docs. They say that Rollup will use the common ancestor of all modules in the
+    //     bundle as the basis for the relative path calculation, but both our temporary file and the page being wrapped
+    //     live in `pages/xyz/`, and they're the only two files in the bundle, so `pages/xyz/`` should be used as the
+    //     root. Unclear why it's not.)
+    //   - As a result of the miscalculation, our proxy module will include `export { helperFunc } from '../utils/helper'`
+    //     rather than the expected `export { helperFunc } from '../../utils/helper'`, thereby causing a build error in
+    //     nextjs..
+    //
+    // Setting `makeAbsoluteExternalsRelative` to `false` prevents all of the above by causing Rollup to ignore imports of
+    // externals entirely, with the result that their paths remain untouched (which is what we want).
+    makeAbsoluteExternalsRelative: false,
+
+    onwarn: () => {
+      // Suppress all warnings - we don't want to bother people with this output
+    },
+
+    output: {
+      // TODO
+      interop: 'auto',
+      // TODO
+      exports: 'named',
+    },
+  });
+
+  const finalBundle = await rollupBuild.generate({
+    format: 'esm',
+  });
+
+  // The module at index 0 is always the entrypoint, which in this case is the proxy module.
+  return finalBundle.output[0].code;
+}