NextJS 11 withSentryConfig returns a function when it should return an object

[tm1000]

• 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

• @sentry/browser
• @sentry/node
• raven-js
• raven-node (raven for node)
• other: @sentry/nextjs

Version:

6.7.2

Description

Utilizing https://docs.sentry.io/platforms/javascript/guides/nextjs/manual-setup/ withSentryConfig is returned directly into module.exports. However it's a function at this level and needs to be executed when sent to module.exports to actually send the settings to NextJS. Otherwise it's just a function that nextjs never exports. This actually ends up breaking any settings anyone has added in Next.config.js because once withSentryConfig does this then nextjs sees theres no webpack key on the object sent to module.exports

[tm1000]

This was due to this PR #3698

Which in reality. The issue was how my next.config.js was setup. What I was doing was running withSentryConfig THEN adding my additional settings to settings. But what I should have been doing was adding my additional settings then sending them into withSentryConfig.

Before:

const settings = withSentryConfig()
settings.eslint = {
	ignoreDuringBuilds: true
};

module.exports = settings;

After:

const settings = {};
settings.eslint = {
	ignoreDuringBuilds: true
};

module.exports = withSentryConfig(settings);

This was a pretty big breaking change for us... probably because we were doing things wrong initially but it's bound to bite additional people

cc @lobsterkatie

[lobsterkatie]

@tm1000 - Thanks for pointing this out.

In that PR I changed withSentryConfig to output a function, because otherwise nextjs won't pass phase and defaultConfig to us in order that we be able to forward them on to any existing config function. That said, that's only necessary if the existing confg that's passed to us is, in fact, a function. I can add a check, and revert to the old return-an-object behavior if we're not given a function.