Using the "filesToDeleteAfterUpload" plugin setting breaks source maps with esbuild plugin

[bryansoftdev]

Environment

• esbuild: 0.15.18
• @sentry/esbuild-plugin: 2.14.1
• @sentry/serverless: 6.15.0

Steps to Reproduce

• Set NODE_OPTIONS=--enable-source-maps environment variable

• serverless.yml:

  custom:
  esbuild:
    exclude:
      - '@aws-sdk'
    plugins: './esbuild.plugins.js'
    sourcemap: true

• esbuild.plugin.js:

  const { sentryEsbuildPlugin } = require('@sentry/esbuild-plugin');
  
  module.exports = [
  sentryEsbuildPlugin({
    authToken: process.env.SENTRY_AUTH_TOKEN,
    org: '...',
    project: '...',
    release: {
      name: process.env.SENTRY_RELEASE,
      setCommits: { auto: true },
    },
    sourcemaps: {
      assets: './.esbuild/.build/**/*',
      filesToDeleteAfterUpload: './.esbuild/.build/**/*.map',
    },
  }),
  ];

I triggered a test event on AWS without changing the default values to make an error occur on purpose. I did it once without the filesToDeleteAfterUpload setting in my config, and then repeated with filesToDeleteAfterUpload set.

Expected Result

Before enabling the filesToDeleteAfterUpload setting:

Actual Result

After enabling the filesToDeleteAfterUpload setting:

[lforst]

NODE_OPTIONS=--enable-source-maps is generally not supported by Sentry as it makes stack traces resolve to the original location which is not what we want when source maps are uploaded. Either you remove that option or you upload sourcemaps. It seems like something didnt work in the second screenshot though. What does the unminify code button say?

[bryansoftdev]

@lforst Thank you, I reviewed what the button said, and I realized my version of the sentry SDK was very out of date. Updating from @sentry/serverless: 6.15.0 to ^7.56.0 fixed the problem.

The stack trace looks better now & my serverless zip has the source maps removed. 👍

(I also removed NODE_OPTIONS=--enable-source-maps like you said)

[lforst]

Awesome, glad it worked for you!