@sentry/nextjs - `_middleware.ts` inside `/pages/api`-dir gets sentry-related code in production build

[klaasman]

• Review the documentation: https://docs.sentry.io/
• Search for existing issues: https://github.com/getsentry/sentry-javascript/issues
• Use the latest release: https://github.com/getsentry/sentry-javascript/releases
• Provide a link to the affected event from your Sentry account

Package + Version

• other: sentry/nextjs

Version:

6.17.4

Description

Any _middleware.ts file inside the /pages/api directory receives sentry-related code in the outputted file. This is not the case as soon as you move this _middleware.ts file outside this api directory.

As a result the function runtime throws an error because sentry tries to access the window:

/Volumes/[...]/.next/server/pages/api/_middleware.js:6121
var manualScrollRestoration =  true && 'scrollRestoration' in window.history && !!function() {
                                                              ^

ReferenceError: window is not defined

[AbhiPrasad]

Hey thanks for writing in. When looking at this line that errored:

var manualScrollRestoration =  true && 'scrollRestoration' in window.history && !!function() {

We don't seem to have any logic like that in the SDK. Doing a search for scrollRestoration also confirms this: https://github.com/getsentry/sentry-javascript/search?q=scrollRestoration&type=. Is it possible that there is some other library causing issues here?

We guard against using window by leveraging a getGlobalObject function internally, that will check for things like window existence.

A reproduction would be very helpful in helping us debug further. If not, a copy of your next.config.js and package.json would be great!

[klaasman]

Thanks for the quick response. Here's a reproduceable repository: https://github.com/klaasman/sentry-javascript-issue-4507

For some reason the erroring line isn't evaluated in that repo, but you should be able to see in the distribution that the _middleware inside the api dir has a lot of code which shouldn't be there. Removing the sentry wrapper in the next.config.js will fix the issue.

Btw, this is currently my workaround for the above issue:

// next.config.js

module.exports = removeErroneousSentryFromMiddleware(configWithSentry);

function removeErroneousSentryFromMiddleware(config) {
  return {
    ...config,
    webpack: (...args) => {
      const webpackConfig = { ...config.webpack(...args) };
      const oldEntry = webpackConfig.entry;

      webpackConfig.entry = async function (...args) {
        const entry = { ...await oldEntry.apply(this, args) };

        Object.entries(entry).forEach(([path, files]) => {
          if (path.endsWith('_middleware') && files.includes('./sentry.client.config.js')) {
            entry[path] = files.filter(entryPoint => entryPoint !== './sentry.client.config.js');
          }
        })

        return entry;
      }

      return webpackConfig;
    }
  };
}

As you can see the sentry.client.config.js becomes part of the /api-middleware entry points:

 'pages/_middleware': 'next-middleware-loader?absolutePagePath=private-next-pages%2F_middleware.js&page=%2F_middleware!',
  'pages/api/_middleware': [
    './sentry.client.config.js',
    'next-middleware-loader?absolutePagePath=private-next-pages%2Fapi%2F_middleware.js&page=%2Fapi%2F_middleware!'
  ],

[AbhiPrasad]

awesome, thank you for the detailed repro and workaround. Will backlog as a bug, but PRs welcome if anyone wants to take a look before we do!

[lobsterkatie]

Hi, @klaasman.

For the moment I've filtered _middleware pages out of sentry injection (in the above-linked PR), so that should fix your problem in the short run. That said, it's on our roadmap to support the new middleware feature, and once that happens, this filter will go away.

What's confusing to me about this whole situation is quite how you're ending up with your API middleware as part of your client build. (You can tell it's the client build and not the server build because only the client build uses loaders that way.) Because it's the client build, it's the client sentry config file which is included (which is correct), and that's pulling in the manualScrollRestoration code from the nextjs router, which is causing the problem.

If you can debug your setup to figure out how api/_middleware (or any API route, for that matter) is ending up as an entrypoint for your client build, that ought to unlock this. The SDK takes the entrypoint list it's given and acts upon it, so you might want to try removing sentry but keeping the skeleton of your workaround, not to filter the entrypoints but just to print them out. I believe you'll find that the rogue API middleware shows up even without sentry involved.

Let us know how you do! I'm curious to know what's causing this.