Typescript Mismatch

[saiichihashimoto]

https://github.com/vercel/next.js/blob/canary/packages/next/server/config-shared.ts#L46
https://github.com/getsentry/sentry-javascript/blob/master/packages/nextjs/src/config/types.ts#L58

The types from @sentry/nextjs and next don't match when it comes to webpack build context. Something as simple as this has a type error:

const { withSentryConfig } = require("@sentry/nextjs");

/**
 * @type {import('next').NextConfig}
 */
const config = {
  webpack: (config) => ({
    ...config,
    module: {
      ...config.module,
      rules: [
        ...config.module.rules,
        someRule,
      ],
    },
  }),
};

module.exports = withSentryConfig(config, {
  validate: true,
});

  TSError: ⨯ Unable to compile TypeScript:
next.config.js:28:35 - error TS2345: Argument of type 'NextConfig' is not assignable to parameter of type 'ExportedNextConfig | undefined'.
  Type 'NextConfig' is not assignable to type 'Partial<NextConfigObject>'.
    Types of property 'webpack' are incompatible.
      Type '((config: any, context: { dir: string; dev: boolean; isServer: boolean; buildId: string; config: NextConfigComplete; defaultLoaders: { babel: any; }; totalPages: number; webpack: any; }) => any) | null | undefined' is not assignable to type 'WebpackConfigFunction | undefined'.
        Type 'null' is not assignable to type 'WebpackConfigFunction | undefined'.

28 module.exports = withSentryConfig(config, {
                                     ~~~~~~

Instead of building our own NextConfigObject type, next exports its own import('next').NextConfig type. We should be extending it to ensure compatibility rather than redefining it and hoping they correlate.

[cdbattags]

Any update on this? I don't think we'll be able to use Sentry without this.

[timfish]

Any update on this? I don't think we'll be able to use Sentry without this.

You can work around the type mismatch issue by using as any:

module.exports = withSentryConfig(config as any, {
  validate: true,
});

Instead of building our own NextConfigObject type, next exports its own import('next').NextConfig type. We should be extending it to ensure compatibility rather than redefining it and hoping they correlate.

@sentry/nextjs needs to support next v10 and v10 doesn't export NextConfig which I'm guessing is why these types have been vendored like this in the first place.

I think I have a fix on the way!