sentry-javascript icon indicating copy to clipboard operation
sentry-javascript copied to clipboard

@sentry/nextjs doesn't respect sourcemaps.filesToDeleteAfterUpload

Open joeldotsh opened this issue 2 years ago • 7 comments

Is there an existing issue for this?

  • [X] I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
  • [X] I have reviewed the documentation https://docs.sentry.io/
  • [X] I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/nextjs

SDK Version

7.59.3

Framework Version

Next 13.4.9 / React 18.2.0

Link to Sentry event

No response

SDK Setup

Sentry.init({
  dsn: ...,
  tracesSampleRate: 1.0
});

Then in my next.config.js:

const nextConfig = {
  ...
}

const sentryWebpackPluginOptions = {
  org: ...,
  project: ...,
  authToken: ...,
  sourcemaps: {
    filesToDeleteAfterUpload: "*.map" // Also tried "**/*.map", ".next/**/*.map", even ".next/*"
  }
};

module.exports = withSentryConfig(nextConfig, sentryWebpackPluginOptions)

Steps to Reproduce

  1. Add the above config to next.config.js
  2. Run next build
  3. Observe sourcemaps are still present in the .next outputs

Expected Result

Expected sourcemaps in the .next outputs to have sourcemaps removed.

According to the docs, the package uses @sentry/webpack-plugin under the hood, which has a sourcemaps.filesToDeleteAfterUpload configuration option. But I wasn't able to get this working (see above next.config.js attempts).

Actual Result

Sourcemaps are still present in the .next outputs.

It appears the filesToDeleteAfterUpload option isn't being respected, or I'm botching the config? If I'm looking at this correctly, the package uses an old version of the webpack plugin, which doesn't support that option. Is that the case? Would it be safe to upgrade this manually and set a yarn resolution? What is the recommended approach here?

Thank you

joeldotsh avatar Jul 20 '23 21:07 joeldotsh

Hi @joeldotsh yes, that's correct, the NextJS SDK still uses v1 of our webpack plugin which doesn't have the same options API as v2. v1 unfortunately doesn't have an option to automatically delete source maps after upload. The best solution is to create a small script to delete them after build. We're looking into upgrading to v2 of the plugin down the road but since this is a breaking API change, it will likely only happen in the next major of the SDK.

You might want to look into the hideSourceMaps option as an alternative

I'm going to close this for the time being. Let me know if you think this should be reopened.

Lms24 avatar Jul 24 '23 09:07 Lms24

Hi there, just upgraded to 8.0.0, which should be on 2.16.0 of the webpack plugin, but even with the config set to

sourcemaps: {
  filesToDeleteAfterUpload: "*.map" // Also tried "build/**/*.map"
}

the .map files still exist after build and successful upload to Sentry.

Curiously, I noticed that the SentryBuildOptions type is missing the sourcemaps.filesToDeleteAfterUpload type definition, so is this not yet fully supported?

cjwang18 avatar May 14 '24 01:05 cjwang18

Hey @cjwang18 you're correct, this functionality is currently missing from the top level NextJS SDK Webpack Plugin options. I believe when we made the switch to v2 of the webpack plugin in NextJS (#10978) there were still some open questions around the best API for this (https://github.com/getsentry/sentry-javascript/pull/10978#discussion_r1519648287). The good news is: for now, you can unblock yourself by specifying unstable plugin options that will override any "stable" settings.

Long story short, I'd recommend trying:

sourcemaps: {
  // whatever other options you add here, if any
},
unstable_sentryWebpackPluginOptions: {
  sourcemaps: {
    filesToDeleteAfterUpload: "**/*.map",
  },
},

The reason why we have these unstable options is because otherwise, we could never bump to a new major version of the webpack plugin without also bumping the SDK major version. We learned this the hard way in pre-v8 SDK versions. As the name implies, options set under unstable_sentryWebpackPluginOptions could break once we bump plugin major versions. For now though, that is not on our radar at all.

Let me know if this workaround unblocks you.

I'm gonna cc @lforst (when you're back) to revisit adding the deletion option to the stable plugin options.

Lms24 avatar May 14 '24 08:05 Lms24

Hey @cjwang18 you're correct, this functionality is currently missing from the top level NextJS SDK Webpack Plugin options. I believe when we made the switch to v2 of the webpack plugin in NextJS (#10978) there were still some open questions around the best API for this (#10978 (comment)). The good news is: for now, you can unblock yourself by specifying unstable plugin options that will override any "stable" settings.

Long story short, I'd recommend trying:

sourcemaps: {
  // whatever other options you add here, if any
},
unstable_sentryWebpackPluginOptions: {
  sourcemaps: {
    filesToDeleteAfterUpload: "**/*.map",
  },
},

The reason why we have these unstable options is because otherwise, we could never bump to a new major version of the webpack plugin without also bumping the SDK major version. We learned this the hard way in pre-v8 SDK versions. As the name implies, options set under unstable_sentryWebpackPluginOptions could break once we bump plugin major versions. For now though, that is not on our radar at all.

Let me know if this workaround unblocks you.

I'm gonna cc @lforst (when you're back) to revisit adding the deletion option to the stable plugin options.

Hi, actually I was wondering why filesToDeleteAfterUpload option was not working on next.js and arrived to this issue while googling

I found unstable_sentryWebpackPluginOptions just a minute a go before you commented and tried as you wrote in the comment. Unfortunately, it seems it's not working and I can still access source map file: example here. (At least with my configuration)


export default withSentryConfig(
  nextConfig,
  {
    // For all available options, see:
    // https://github.com/getsentry/sentry-webpack-plugin#options

    // Suppresses source map uploading logs during build
    silent: true,
    org: "onycom-test",
    project: "miro-clone",
    sourcemaps: {},
    unstable_sentryWebpackPluginOptions: {
      sourcemaps: {
        filesToDeleteAfterUpload: "**/*.map",
      },
    },
  },
  {...}
)

and I deployed with vercel.

keonil-onycom avatar May 14 '24 09:05 keonil-onycom

Hmm that's not great 😢 sorry for the troubles! if you add debug: true do you get any logs around deletions? Just wondering if my glob was correct after all...

export default withSentryConfig(
  nextConfig,
  {
    // For all available options, see:
    // https://github.com/getsentry/sentry-webpack-plugin#options

    // Suppresses source map uploading logs during build
    // silent: true, <-- disable
    debug: true // <-- add
    org: "onycom-test",
    project: "miro-clone",
    sourcemaps: {},
    unstable_sentryWebpackPluginOptions: {
      sourcemaps: {
        filesToDeleteAfterUpload: "**/*.map",
      },
    },
  },
  {...}
)

I will add this to our list of post-v8 issues to look at immediately.

Lms24 avatar May 14 '24 09:05 Lms24

@keonil-onycom the filesToDeleteAfterUpload option adheres to the glob as far as pattern matching goes, meaning you probably need to define a relative path like ./**/*.js.map.

As soon as all the dust around v8 has settled I will look into adding an automated option to deleting source maps after upload.

lforst avatar May 14 '24 09:05 lforst

@Lms24 @lforst Appreciate your quick responses but unfortunately, like @keonil-onycom, I'm still unable to get it to work as desired.

  // silent: true,
  debug: true,
  // did not define `sourcemaps: {}` as I don't have additional configuration
  unstable_sentryWebpackPluginOptions: {
    sourcemaps: {
      filesToDeleteAfterUpload: "./**/*.map",
    },
  },

Not sure if it matters but I've configured Next to export static into ./build.

In my full build logs, I see Source Map Upload Report being printed 3 times.

In the 1st report, there are about 15 scripts and sourcemaps, but none of which seem to be relevant to my actual statically exported output. I do see it printing tons of "Deleting asset after upload" messages, but all deletions are happening inside node_modules, and none within my configured build directory.

The 2nd report only contains 2 scripts and seem related to Next edge-related files, and not relevant for me.

The 3rd report contains the source maps that I would like to upload and then delete. However, for both the 2nd and 3rd reports, no deletion messages are printed.

I tried another pass by updating my config to only include the build output directory I'm interested in:

  sourcemaps: {
    assets: `${paths.appBuild}/**/*`,
  },
  // Delete sourcemaps after they've been uploaded to Sentry
  // https://github.com/getsentry/sentry-javascript/issues/8600
  unstable_sentryWebpackPluginOptions: {
    sourcemaps: {
      filesToDeleteAfterUpload: `${paths.appBuild}/**/*.map`,
    },
  },

But with this, I no longer see any deletion messages. Source maps are still being uploaded.

Interestingly, I see [@sentry/nextjs - Client] Debug: No sourcemaps.assets option provided, falling back to uploading detected build artifacts. even though I have it defined.


EDIT: For now I've created a simple node script that will remove all map files and I've sequenced it to run after the build process completes on CI.

cjwang18 avatar May 14 '24 19:05 cjwang18

SDK Version 8

Framework Version Next 13.4.2 / React 18.2.0

I have same error.

both doesn't work.

unstable_sentryWebpackPluginOptions: {
    sourcemaps: {
      filesToDeleteAfterUpload: './**/*.js.map',
    },
},
sourcemaps: {
      filesToDeleteAfterUpload: './**/*.js.map',
},

Is this a bug? Is there no solution yet?

oungo avatar Jun 11 '24 04:06 oungo

I finally got round to debugging this. I just tried it in a test app of mine with the setting:

  unstable_sentryWebpackPluginOptions: {
    sourcemaps: {
      filesToDeleteAfterUpload: './.next/**/*.map',
    },
  },

And it worked perfectly fine. Would anybody mind sharing a reproduction example? Thanks!

lforst avatar Jun 11 '24 11:06 lforst

@lforst Just wanted to say your fix worked for me. Thank you so much for taking the time to follow up on this issue

woahitsraj avatar Jan 31 '25 19:01 woahitsraj