feat(ember)!: Update to v2 addon format

[aklkv]

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 JS-217

[nicohrubec]

Hey, thanks for contributing. A few notes:

1. This PR is way too large. Please split it up into smaller pieces so we can review it properly.
2. 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]

Hey, thanks for contributing. A few notes:

1. This PR is way too large. Please split it up into smaller pieces so we can review it properly.
2. 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:

1. Consumer-facing setup — how users configure the SDK (direct Sentry.init() calls instead of ENV['@sentry/ember'])
2. 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!

[johanrd]

@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!

[ijlee2]

I left my review and suggestions for this pull request in aklkv#1.

Here's my message to @aklkv on Ember Discord:

Overall, nice job. I only checked the source code, not the files or configuration for demo-app or tests.

I think it'd help users of @sentry/ember if the only import path that they need to know is the barrel file, and help reviewers of your PR if you split the source code into multiple files. The latter has the benefit of improving the maintainability for the future.

I saw that you pushed a new commit after I was about to open my PR. It's possible that I missed something from your new commit while fixing the merge conflicts.

[aklkv]

I left my review and suggestions for this pull request in aklkv#1.

@ijlee2 this is great 💚 would you mind rebasing pleas, I would be happy integrating this changes

[ijlee2]

I left my review and suggestions for this pull request in aklkv#1.

@ijlee2 this is great 💚 would you mind rebasing pleas, I would be happy integrating this changes

@aklkv Done rebasing.

[aklkv]

@mydea will you be able to take this over the finish line?

[github-actions]

This pull request has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you apply the label PR: no-auto-close I will leave it alone ... forever!

[jiayingxu]

Hey folks 👋 wanted to add a data point here, and also flag that this PR looks close to getting auto-closed by the stale bot again — would be a shame, since it's genuinely the fix we're waiting on.

We're in the middle of upgrading from ember-source 6.12 → 7.1 in a fairly large app, and we're hitting a real build-breaking issue with @sentry/ember along the way. We're still partially on classic V1 addons via @embroider/compat's classic-addon-transpile step, and @sentry/ember is one of the few addons that directly depends on @embroider/macros and calls setOwnConfig() in its included() hook. That runs into the known ordering bug where @embroider/compat transpiles V1 addons before MacrosConfig.finalize() has run (tracked upstream at embroider-build/embroider#1574, open since 2023):

[Embroider:MacrosConfig] cannot read userConfigs until MacrosConfig has been finalized.

This is exactly why moving @sentry/ember to the V2 addon format (as this PR does) fixes it for good, rather than just working around it: V2 addons skip @embroider/compat's classic-addon-transpile pipeline entirely, so the finalize() ordering bug never comes into play. We actually don't even use the ENV['@sentry/ember']/getOwnConfig() config path — we already call Sentry.init() directly — so just to double-check the root cause rather than assume, we tried a local patch that strips the macros wiring out of @sentry/ember's index.js, and that confirmed it. We'd rather not maintain a patched fork long-term though, so this PR is the fix we're really hoping lands.

No pressure at all given everyone's clearly busy, but wanted to add our +1 that this would unblock real Ember 7 upgrades for apps in a similar mid-migration spot. @mydea @nicohrubec — thanks for all the work on this already, and hope it gets a chance to land soon! 🙏

[aklkv]

@jiayingxu while we wait for this to land may I suggest escape hatch which we use today, you can add this to vite.config.mjs -> process.env.I_HAVE_BAD_PEER_DEPS_AND_WANT_A_BROKEN_BUILD = '1';
I will however be a little noisy during the build as well as we use a patch to drop Ember. usage. With this two in place we are able to run embroider/vite + ember 7.1

[jiayingxu]

Thanks for the suggestion @aklkv! We tested this in our application, and the Vite build passes with Ember 7.1 using I_HAVE_BAD_PEER_DEPS_AND_WANT_A_BROKEN_BUILD. We’d rather not ship with that flag enabled, though, so we’ll wait for the V2 addon update before upgrading to Ember 7. We really appreciate you suggesting the workaround, even though it isn’t something we’d prefer to use in production.

[NullVoxPopuli]

there is a way to patch this with pnpm patch

1. clone the repo
2. cd in
3. checkout @aklkv's branch
4. install && build
5. make note of the CWD

then in your repo

1. pnpm patch @sentry/ember
2. cd to the directory it prints
3. cp the directory you cloned @sentry/javascript in to the patch directory
4. pnpm patch commit
5. git commit 1 giant patch file

[mydea]

Rebased this onto current develop (it was ~1900 commits behind and conflicting) and fixed the failing tests in #23252. That PR resolves the merge conflicts, ports the span-op / URL-attribute changes that landed on develop after this branch, re-applies the TypeScript 7 build workaround, and gets all four ember e2e apps green. Continuation of this PR — credit to @aklkv for the original migration.

[mydea]

I created a new PR based on this because there were so many conflicts, but thank you a lot - see #23252