Export Integrations (and other potential things) individually for proper treeshaking support

[mortargrind]

• Review the documentation: https://docs.sentry.io/
• Search for existing issues: https://github.com/getsentry/sentry-javascript/issues
• Use the latest release: https://github.com/getsentry/sentry-javascript/releases

Package + Version

• @sentry/browser
• @sentry/node

Version:

15.19.1 and below

Description

Integrations (actually not just them, everything) should be exported individually using named exports, instead of using namespace objects like Integrations so unused integrations (or any other thing) won't be included in the bundle. Right now If I include any integrations (like LinkedErrors integration) I am forced to include every possible integration, which unnecessarily increases the bundle size. Also, in the case of this issue: #2688 it results in loading a server-side module on browser-side (and vice-versa), which is a much bigger problem that not just affects performance but also functionality.

I think this can be done in a minor update via keeping the old Integrations style exports but directing people to using the new individual exports. I can try to add this with a PR if you want.

[kamilogorek]

Any improvement (especially bundle-size wise) that's backward compatible is more than welcome! :)

[mortargrind]

Hello again @kamilogorek

I have very recently began working on this issue and I have noticed that fixing this 100% will result in a breaking change because the init function itself imports all the defaultIntegrations so even if the consumer won't use the default integrations, they will be included in the bundle. This means even if we stop using all the unnecessary namespace objects and import the integrations we want to use manually, default ones will be still there.

Instead of adding the default integrations by default and only accepting the overrides from the consumer; default ones could be exported separately and passed manually by the consumer. OR, Sentry can have two init functions, one is minimal init that accepts everything as parameter and does not import anything unnecessary by default. The other one is something like initWithDefaults, if you are worried that people would forget to import defaultIntegrations and pass it to init, they can use initWithDefaults. Those who want granular control on the bundle size can use the minimal init.

I would go for the first approach BTW: just having one init function that does not import anything by default and require every use to declare & import their integrations manually (also exporting a default/recommended integrations).

And also, WDYT about a 100% fix being a breaking change? Should this change wait for v6 completely or should I first try to add individually importable integrations and keep the defaultIntegrations being imported automatically for now with a minor version update?

[kamilogorek]

And also, WDYT about a 100% fix being a breaking change? Should this change wait for v6 completely or should I first try to add individually importable integrations and keep the defaultIntegrations being imported automatically for now with a minor version update?

This is one of the things that we'll definitely fix in the V6. We have not yet decided on the concrete solution, but your insights are definitely valuable, thanks!

[github-actions]

This issue 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 label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀