Skip to content

Not use Babel for adding debug information during build #718

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
spaceemotion opened this issue Apr 3, 2025 · 1 comment
Open

Not use Babel for adding debug information during build #718

spaceemotion opened this issue Apr 3, 2025 · 1 comment

Comments

@spaceemotion
Copy link

spaceemotion commented Apr 3, 2025

I wanted to try out the new Rolldown version of Vite for building our web app. Without the Sentry plugin, the whole build takes about 8 seconds.

However, with the Sentry plugin, this shoots up back to about 24 seconds again - so a 3x increase. I tried looking for why that could be the case and saw that files are being modified using Babel.

Our current Vite build takes about 30 seconds, with or without Sentry.

Here's the current configuration for the Sentry plugin that we're using:

sentryVitePlugin({
  disable: !process.env.SENTRY_RELEASE,
  telemetry: false,

  org: process.env.SENTRY_ORG,
  project: process.env.SENTRY_PROJECT,

  release: {
    dist: process.env.SENTRY_DIST,

    setCommits: {
      auto: true,
      ignoreEmpty: true,
      ignoreMissing: true,
    },
  },

  bundleSizeOptimizations: {
    excludeDebugStatements: true,
    excludeReplayShadowDom: true,
    excludeReplayIframe: true,
    excludeReplayWorker: true,
  },
}),

Are there plans to use a faster/more modern way of handling these things?

Thanks in advance!

@getsantry getsantry bot moved this to Waiting for: Product Owner in GitHub Issues with 👀 3 Apr 3, 2025
@lforst
Copy link
Contributor

lforst commented Apr 3, 2025

As long as you don't use reactComponentAnnotations the plugin will not use babel to transform things. Ideally you profile your build somehow to figure out what exactly is slow. In general, the actual upload of the sourcemaps will probably take the longest because it is strongly I/O bound and requires quite a bit of memory.

Currently we don't have any short term plans to specifically support rolldown. At some point we will!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

No branches or pull requests

3 participants