feat(ember): v2 by aklkv · Pull Request #19229 · getsentry/sentry-javascript

aklkv · 2026-02-08T07:04:23Z

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

If you've added code that should be tested, please add tests.
Ensure your code lints and the test suite passes (yarn lint) & (yarn test).
Link an issue if there is one related to your pull request. If no issue is linked, one will be auto-generated and linked.

Summary

Migrates @sentry/ember from the legacy v1 addon format to the Ember v2 addon format. This modernizes the package to work with both classic Ember builds and Embroider-optimized builds, and removes the runtime dependency on @embroider/macros.

Changes

Build system: Replaced ember-cli build pipeline with rollup (transpilation → dist/) + tsc (declarations → declarations/)
Addon entry: Added addon-main.cjs using @embroider/addon-shim as the addon entry point
Package.json: Set ember-addon.version: 2, updated exports map, added ember-addon.app-js mapping
Config format: Replaced @embroider/macros getOwnConfig() with explicit Sentry.init() calls and a new setupPerformance() export

API changes:

init() is now called directly in app.ts or an initializer (no more ENV['@sentry/ember'] config)
setupPerformance() must be called from an instance-initializer to opt into performance instrumentation
Initial load instrumentation requires manual <script> tags in index.html
Added UPGRADE.md with detailed migration guide

Test & CI updates:

All 21 unit tests passing (acceptance tests for errors, performance, and replay)
Updated e2e test apps (ember-classic, ember-embroider) to use v2 patterns:
- Added instance-initializers for performance setup
- Migrated config from ENV['@sentry/ember'] to Sentry.init() in app.ts
- Added initial load <script> tags to index.html
Updated .github/workflows/build.yml CACHED_BUILD_PATHS from packages/ember/*.d.ts to packages/ember/dist + packages/ember/declarations

TypeScript fixes:

Added "types": ["ember-source/types"] to tsconfig.publish.json for Ember module resolution during declaration generation
Fixed transition type imports (removed non-existent @ember/routing/-private/transition)
Simplified instrumentFunction generic to avoid tuple mismatch errors

Breaking Changes

ENV['@sentry/ember'] config in config/environment.js is no longer supported — use Sentry.init() directly
Performance instrumentation is no longer automatic — call setupPerformance() from an instance-initializer
Initial load tracking requires manual <script> tags in app/index.html

Closes #15835

nicohrubec

Hey, thanks for contributing. A few notes:

This PR is way too large. Please split it up into smaller pieces so we can review it properly.
Is there a way to get this done without introducing breaking changes? If no, then we need to wait with this until our next major.

aklkv · 2026-02-09T11:24:12Z

Hey, thanks for contributing. A few notes:

This PR is way too large. Please split it up into smaller pieces so we can review it properly.

Is there a way to get this done without introducing breaking changes? If no, then we need to wait with this until our next major.

Hi @nicohrubec, thanks for the feedback!

I understand the concern about PR size. Unfortunately, the v1 → v2 addon migration is an atomic change — you can't incrementally migrate between formats. The build pipeline, entry point structure, and package.json layout must change together for the addon to function.

That said, the core SDK functionality is unchanged — the same instrumentation, error handling, and performance tracking code. The changes fall into two categories:

Consumer-facing setup — how users configure the SDK (direct Sentry.init() calls instead of ENV['@sentry/ember'])
Build/packaging scaffolding — the surrounding v2 addon infrastructure (Rollup config, addon-main.cjs, exports map, etc.)

The actual instrumentation logic in src/ is largely untouched. So while the diff is large, most of it is build tooling and test app updates to match the new setup pattern — not changes to Sentry functionality itself.

I'm happy to:

Add a review guide in the PR description highlighting which files contain meaningful changes vs. scaffolding
Split into multiple logical commits (build system, config API, test updates) to make review easier

Regarding breaking changes — the v2 format requires explicit Sentry.init() calls, so this would need to target the next major release.

Let me know how you'd like to proceed!

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

cursor · 2026-02-09T12:33:55Z

packages/ember/src/index.ts

+  const _global = GLOBAL_OBJ as typeof GLOBAL_OBJ & GlobalConfig;
+  _global.__sentryEmberConfig = _global.__sentryEmberConfig ?? {};
+  return _global.__sentryEmberConfig;
+}


Unused global config storage mechanism is dead code

Low Severity

The _getSentryInitConfig() function stores init configuration in a global variable (__sentryEmberConfig), but this global is never read anywhere in the codebase. In the v1 addon, the performance module used getSentryConfig() to read both environment and global config, but that function was removed during migration. The new setupPerformance() takes options directly via parameters. The _getSentryInitConfig call in init(), the GlobalConfig type, and the comment "Persist Sentry init options for reference" are all vestigial code that adds unnecessary complexity.

Additional Locations (2)

packages/ember/src/index.ts#L166-L169

packages/ember/src/types.ts#L31-L34

@aklkv is this true?

johanrd · 2026-02-09T12:47:36Z

@aklkv thanks a lot for doing this!🙏

FWIW: While waiting for this, I realized I didn't use the performance part of the addon, and was able to just use the @sentry/browser package without the need of any ember specific addon at all.

That also means that the 'breaking change' mentioned in the PR is a very welcome change to reduce the scope of what is delegated to the 'ember' part of the addon. Most is now just handled by the core apis, which it how it should be👍

(the link to Ember v2 addon format is broken in the pr description, btw)

NullVoxPopuli

This is a good PR.

I understand the maintainer's perspective of wanting it split up tho.

The only way to do so would be rearranging the monorepo a bit to make a separate test app package.

This would mean the goal of that PR is to just delete the dummy app from the existing v1 addon.

That will still be a large pr, and i don't really see a way to get better than 2 large prs for this needed work.

Maintainers,
You mentioned breaking change timing - i suspect that is because all packages in this repo are released at once?

May i introduce you to https://github.com/release-plan/release-plan ?
It allows each package to be published independently with correct semver inference based on changes in git (and labels assessing impact on a pr) it helps a lot!

NullVoxPopuli · 2026-02-09T13:02:41Z

dev-packages/e2e-tests/test-applications/ember-classic/app/index.html

    <meta name="description" content="">
    <meta name="viewport" content="width=device-width, initial-scale=1">

+    <script>if(window.performance&&window.performance.mark){window.performance.mark('@sentry/ember:initial-load-start');}</script>


What are these additions for? Are they needed?

NullVoxPopuli · 2026-02-09T13:04:19Z

.../e2e-tests/test-applications/ember-embroider/app/instance-initializers/sentry-performance.ts

Since this is an app file, did the readme get updated to reflect the situation that wants this added?

Is it required?

NullVoxPopuli · 2026-02-09T13:05:54Z

packages/ember/addon/runloop.d.ts

Good riddance

NullVoxPopuli · 2026-02-09T13:06:46Z

packages/ember/demo-app/routes/with-loading/index.ts

+  }
+}
+
+export default instrumentRoutePerformance(WithLoadingIndexRoute);


Nice way to do this!

NullVoxPopuli · 2026-02-09T13:10:25Z

packages/ember/src/index.ts

+  const _global = GLOBAL_OBJ as typeof GLOBAL_OBJ & GlobalConfig;
+  _global.__sentryEmberConfig = _global.__sentryEmberConfig ?? {};
+  return _global.__sentryEmberConfig;
+}


@aklkv is this true?

NullVoxPopuli · 2026-02-09T13:15:01Z

packages/ember/UPGRADE.md

Ah! My questions were answered here in this doc! Tyty!

aklkv marked this pull request as ready for review February 8, 2026 09:40

aklkv force-pushed the feat/ember-v2-format branch 3 times, most recently from 53dd617 to 822ed0a Compare February 8, 2026 11:01

nicohrubec requested changes Feb 9, 2026

View reviewed changes

feat(ember): Migrate @sentry/ember to v2 addon format

4874c99

aklkv force-pushed the feat/ember-v2-format branch from 822ed0a to 4874c99 Compare February 9, 2026 12:25

cursor bot reviewed Feb 9, 2026

View reviewed changes

NullVoxPopuli reviewed Feb 9, 2026

View reviewed changes

Uh oh!

Conversation

aklkv commented Feb 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Breaking Changes

Uh oh!

nicohrubec left a comment

Choose a reason for hiding this comment

Uh oh!

aklkv commented Feb 9, 2026

Uh oh!

cursor bot left a comment

Choose a reason for hiding this comment

Uh oh!

cursor bot Feb 9, 2026

Choose a reason for hiding this comment

Unused global config storage mechanism is dead code

Uh oh!

NullVoxPopuli Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

johanrd commented Feb 9, 2026

Uh oh!

NullVoxPopuli left a comment

Choose a reason for hiding this comment

Uh oh!

NullVoxPopuli Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

NullVoxPopuli Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

NullVoxPopuli Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

NullVoxPopuli Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

NullVoxPopuli Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

NullVoxPopuli Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

aklkv commented Feb 8, 2026 •

edited

Loading