feat: integrate Sentry Rollup plugin for source map uploads

[Copilot]

Adds automatic source map upload to Sentry during production builds via the Sentry Rollup plugin.

Changes

• Build configuration: Added @sentry/rollup-plugin to tsdown.config.ts with environment-based auth (SENTRY_ORG, SENTRY_PROJECT, SENTRY_AUTH_TOKEN)
• Environment template: Documented required Sentry variables in .env.sample
• Git ignore: Added .env.sentry-build-plugin to prevent credential leakage

Behavior

Build continues successfully when Sentry credentials are absent (warnings only). Source maps upload automatically when credentials are configured via environment variables or .env.sentry-build-plugin file.

plugins: [
  sentryRollupPlugin({
    org: process.env.SENTRY_ORG,
    project: process.env.SENTRY_PROJECT,
    authToken: process.env.SENTRY_AUTH_TOKEN,
    sourcemaps: { assets: ["./dist/**/*.map"] },
    release: { name: version },
  }),
],

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Sentry Source Maps</issue_title>
<issue_description>Install Sentry Rollup Plugin into tsdown build

import { defineConfig } from "tsdown";

export default defineConfig({
  entry: ["src/**/*.ts", "!src/**/*.test.ts"],
  format: ["cjs", "esm"],
  dts: true,
  sourcemap: true,
  clean: true,
  external: [
    // Only mark test-only packages as external
    "@sentry/mcp-server-mocks",
    // Everything else (including @sentry/mcp-core) will be bundled
  ],
  env: {
    SENTRY_ENVIRONMENT: "stdio",
    npm_package_version: "{{version}}",
  },
});

Manual Setup
Install the Sentry Rollup plugin:

npm
yarn
pnpm

Copied
npm install @sentry/rollup-plugin --save-dev
Configuration
To upload source maps you have to configure an Organization Token.

Alternatively, you can also use a Personal Token, with the "Project: Read & Write" and "Release: Admin" permissions.

Auth tokens can be passed to the plugin explicitly with the authToken option, with a SENTRY_AUTH_TOKEN environment variable, or with an .env.sentry-build-plugin file (don't forget to add it to your .gitignore file, as this is sensitive data) in the working directory when building your project. We recommend you add the auth token to your CI/CD environment as an environment variable.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Sentry Source Maps #214

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

✨ PR Description

Purpose: Integrate Sentry Rollup plugin to automatically upload source maps during build process for improved error tracking and debugging in production.

Main changes:

• Added @sentry/rollup-plugin to tsdown config with org, project, and auth token configuration
• Configured source map uploads to Sentry with release versioning tied to package version
• Added SENTRY_ORG, SENTRY_PROJECT, and SENTRY_AUTH_TOKEN environment variables to CI workflows
• Updated documentation with instructions for configuring Sentry secrets in GitHub Actions

Generated by LinearB AI and added by gitStream.
_{AI-generated content may contain inaccuracies. Please verify before using.
💡 Tip: You can customize your AI Description using Guidelines Learn how}

---

Note

Enables automatic source map upload to Sentry during builds while remaining no-op without credentials.

• Adds @sentry/rollup-plugin in tsdown.config.ts with release name from package.json and sourcemaps glob ./dist/**/*.map
• Exposes SENTRY_ORG, SENTRY_PROJECT, SENTRY_AUTH_TOKEN in GitHub Actions build steps (build-and-test.yml, release.yml)
• Documents Sentry secrets in .env.sample and setup instructions in README.md
• Ignores .env.sentry-build-plugin in .gitignore
• Adds devDependency @sentry/rollup-plugin and updates lockfile

^{Written by Cursor Bugbot for commit 3f947fd. This will update automatically on new commits. Configure here.}

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch copilot/install-sentry-rollup-plugin

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gitstream-cm]

✨ PR Review

LGTM

Generated by LinearB AI and added by gitStream.
_{AI-generated content may contain inaccuracies. Please verify before using.
💡 Tip: You can customize your AI Review using Guidelines Learn how}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 65.60%. Comparing base (4fe598f) to head (3f947fd).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #215   +/-   ##
=======================================
  Coverage   65.60%   65.60%           
=======================================
  Files          13       13           
  Lines         407      407           
  Branches      127      127           
=======================================
  Hits          267      267           
  Misses         92       92           
  Partials       48       48           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[charliecreates]

Main concern: Sentry uploads are not explicitly gated to “production” and can run in any environment where SENTRY_* variables are present, which risks accidental/undesired release creation and sourcemap uploads. Additionally, injecting Sentry secrets into the general CI build job broadens exposure and increases the chance of uploads from non-release builds. Documentation around token scopes should be verified against current Sentry Rollup plugin requirements to avoid setup failures.

Additional notes (1)

• Maintainability | README.md:325-339
  The README states the auth token needs project:releases scope. Sentry’s recommended scopes for sourcemap uploads commonly include project:releases and org:read (and sometimes project:read). If the scope guidance is wrong/incomplete, setup will fail in a confusing way and the build will emit warnings.

At minimum, this should align with Sentry’s current docs (and preferably mention the exact scopes needed).

Summary of changes

What this PR changes

Build: Sentry source map upload

• Adds @sentry/rollup-plugin to tsdown.config.ts and wires it into the plugins array via sentryRollupPlugin({ ... }).
• Configures plugin inputs from environment (SENTRY_ORG, SENTRY_PROJECT, SENTRY_AUTH_TOKEN), disables plugin telemetry, uploads ./dist/**/*.map, and sets the Sentry release.name to the package version.

CI / workflows

• Passes Sentry secrets into the build step in:
  • .github/workflows/build-and-test.yml
  • .github/workflows/release.yml

Docs & repo hygiene

• Documents Sentry env vars in .env.sample.
• Ignores .env.sentry-build-plugin in .gitignore.
• Adds README instructions for configuring Sentry secrets in GitHub Actions.

Dependencies

• Adds @sentry/rollup-plugin@^4.6.1 (and lockfile updates) to support the build integration.

[charliecreates]

sentryRollupPlugin(...) is always enabled, which means any environment that happens to have SENTRY_* variables set (including local dev or non-prod CI jobs) will attempt to create releases/upload sourcemaps. That can lead to accidental uploads from feature branches or PR builds, and it’s difficult to reason about when uploads should happen.

Given the PR intent (“during production builds”), this should be explicitly gated (e.g., CI && main branch, or a SENTRY_UPLOAD_SOURCEMAPS=true flag, or NODE_ENV=production).

Suggestion

Consider conditionally enabling the plugin and/or passing dryRun when not in a release build. For example:

const shouldUpload =
  process.env.SENTRY_UPLOAD_SOURCEMAPS === "true" ||
  (process.env.CI === "true" && process.env.GITHUB_REF === "refs/heads/main");

export default defineConfig({
  // ...
  plugins: shouldUpload
    ? [
        sentryRollupPlugin({
          org: process.env.SENTRY_ORG,
          project: process.env.SENTRY_PROJECT,
          authToken: process.env.SENTRY_AUTH_TOKEN,
          telemetry: false,
          sourcemaps: { assets: ["./dist/**/*.map"] },
          release: { name: version },
        }),
      ]
    : [],
});

This makes “production builds” explicit and prevents accidental uploads. Reply with "@CharlieHelps yes please" if you'd like me to add a commit with this suggestion.

[charliecreates]

The release is set to version only. That can easily collide across different repos/environments and makes it hard to correlate a Sentry release back to a specific commit/build. Sentry generally benefits from a unique release identifier (e.g., name@version+sha or name@version with a dist).

Also, without a dist (or commit SHA in release), rebuilding the same version can overwrite artifacts unexpectedly or create confusing state.

Suggestion

Make the release identifier unique and/or set a dist.

Options:

1. Include commit SHA in release name:

const sha = process.env.GITHUB_SHA ?? process.env.VERCEL_GIT_COMMIT_SHA;
const releaseName = sha ? `${version}-${sha.slice(0, 7)}` : version;
// release: { name: releaseName }

2. Keep release.name = version but add dist (e.g., run number / sha):

release: { name: version, dist: process.env.GITHUB_RUN_NUMBER ?? "local" }

Reply with "@CharlieHelps yes please" if you’d like me to add a commit with one of these options.

[charliecreates]

Injecting Sentry secrets into build-and-test means the build step will attempt Sentry uploads on all CI runs where secrets are available. That includes PRs from the same repo (not forks), feature branches, and potentially scheduled builds—risking noise in Sentry releases and polluted artifacts.

If you only want uploads for releases, keep secrets limited to the release workflow/job or gate this step by branch/event.

Suggestion

Gate the env injection (or the build step) so Sentry secrets are only present on main (or on push events) and not on PRs. Example:

- name: Run build
  if: github.event_name != 'pull_request' && github.ref == 'refs/heads/main'
  run: pnpm run build
  env:
    SENTRY_ORG: ${{ secrets.SENTRY_ORG }}
    SENTRY_PROJECT: ${{ secrets.SENTRY_PROJECT }}
    SENTRY_AUTH_TOKEN: ${{ secrets.SENTRY_AUTH_TOKEN }}

Or set SENTRY_UPLOAD_SOURCEMAPS: 'true' only in the release workflow and gate in tsdown.config.ts. Reply with "@CharlieHelps yes please" if you'd like me to add a commit with this suggestion.