Repository navigation
Closed
Description
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.
Reacted by no, Garrick Krol, mizdra, Nikita Varabei, Alexander Lee, Ali Mirlou, Tomohiro Hiratsuka, Amit, Pedro Ferreira, Mark Schewe and 1 more
Metadata
Metadata
Assignees
Labels
No labels
Activity
cdbattags commentedon Sep 22, 2022
Any update on this? I don't think we'll be able to use Sentry without this.
timfish commentedon Oct 14, 2022
You can work around the type mismatch issue by using
as any:@sentry/nextjsneeds to support next v10 and v10 doesn't exportNextConfigwhich 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!