Re-examine usage of sentry-cli and bundler plugins

Problem Statement

https://github.com/getsentry/sentry-javascript/issues/4894#issuecomment-1193216873 brings up sentry-cli size issues.

Essentially, due to sentry-cli’s binary size, we require users to have some kind of bundling setup to make sure that they tree shake away sentry-cli in application code.

Is there a way we can improve this situation?

There’s also the concern here with bundlers. Right now we only have a single 1st party plugin, for webpack: https://github.com/getsentry/sentry-webpack-plugin

There is also a community vite plugin:

• https://github.com/ikenfin/vite-plugin-sentry

The more bundlers we support, the better the out of the box experience is (less finagling with sentry-cli).

Solution Brainstorm

Sentry-cli usage

My musings from slack for the sentry-cli size problem:

1. Produce a minimized version of sentry-cli that pretty much only exposes the API around sourcemaps/releases
2. Expand the amount of bundler plugins we have, (go from just webpack -> rollup, webpack, vite, esbuild, we know how to do this)
3. Make sure the framework SDKs include a bundler plugin, and those bundler plugins only use the minimal sentry-cli. Another option here is that we can try making adding build time plugins/steps a Step 2 in the onboarding wizard (after yarn add and Sentry.init). Mobile has something similar where you need to explicitly add the gradle plugin for Android for ex.

Note: We’ll need to DACI how exactly we make sentry-cli smaller, basically choose between re-writing the needed functionality in JS vs. stripping the CLI rust binary at compile time.

Bundlers

There is https://github.com/unjs/unplugin, which allows us to have a single codebase for bundlers (perhaps in the SDK monorepo 👀). It also uses the rollup plugin API, which @lobsterkatie does have a lot of experience with.

@asonnleitner did some awesome work with https://github.com/asonnleitner/unplugin-sentry as per https://github.com/getsentry/sentry-javascript/discussions/4989. We can def use that as a starting point!

[AbhiPrasad]

If we proceed with https://github.com/unjs/unplugin, we’ll go in knowing we have to contribute back upstream - maybe we can fix those inconsistencies?

[lobsterkatie]

• I think trying to reduce the size of the existing Sentry CLI is the wrong angle of attack: Unnecessary complexity + will grow again when new features are added. As a quick fix, maybe, but it’s not a sustainable solution.

If this were done as a proverbial Pick<sentry-cli, 'releases' | 'sourcemaps'> rather than an Omit<sentry-cli, 'all' | 'of' | 'the' | 'other' | 'many' | 'commands'>, I don’t see why it would grow significantly over time.

I’m not philosophically against your translate-everything-to-js idea, but it does seem like it’d be more work (and more maintenance) than just wrapping a stripped-down cli tool.