feat(integrations): Export pluggable integrations directly

[mydea]

This PR re-exports all pluggable integrations from @sentry/integrations from the browser/node packages.

This mean you can use them like this:

import * as Sentry from '@sentry/browser';

Sentry.init({
  // other stuff
  integrations: [
    new Sentry.Integrations.ExtraErrorData()
  ]
});

We already depend on treeshaking in a bunch of other places, and this change means there is really nothing you'd ever need to install manually in addition to your SDK package, also ensuring we generally always have consistent versions etc.

[mydea]

Without this change, this fails for all tests as the build output of webpack includes the import from @sentry/integrations by default and tries to "fix" it in there, but it also does not contain an imported field so it just fails.

[mydea]

This would have been a circular dependency, so got rid of this (similar to what we had to do for replay)

[github-actions]

size-limit report 📦

Path	Size
@sentry/browser (incl. Tracing, Replay) - Webpack (gzipped)	75.19 KB (+0.46% 🔺)
@sentry/browser (incl. Tracing) - Webpack (gzipped)	31.17 KB (+0.2% 🔺)
@sentry/browser - Webpack (gzipped)	21.85 KB (+0.19% 🔺)
@sentry/browser (incl. Tracing, Replay) - ES6 CDN Bundle (gzipped)	69.72 KB (+0.27% 🔺)
@sentry/browser (incl. Tracing) - ES6 CDN Bundle (gzipped)	28.18 KB (+0.1% 🔺)
@sentry/browser - ES6 CDN Bundle (gzipped)	20.18 KB (+0.05% 🔺)
@sentry/browser (incl. Tracing, Replay) - ES6 CDN Bundle (minified & uncompressed)	219.95 KB (+0.41% 🔺)
@sentry/browser (incl. Tracing) - ES6 CDN Bundle (minified & uncompressed)	84.78 KB (+0.13% 🔺)
@sentry/browser - ES6 CDN Bundle (minified & uncompressed)	59.86 KB (+0.04% 🔺)
@sentry/browser (incl. Tracing) - ES5 CDN Bundle (gzipped)	31.04 KB (+0.09% 🔺)
@sentry/react (incl. Tracing, Replay) - Webpack (gzipped)	75.21 KB (+15.62% 🔺)
@sentry/react - Webpack (gzipped)	21.88 KB (+0.18% 🔺)
@sentry/nextjs Client (incl. Tracing, Replay) - Webpack (gzipped)	93.03 KB (+0.41% 🔺)
@sentry/nextjs Client - Webpack (gzipped)	50.7 KB (+0.19% 🔺)

[lforst]

h: This will not tree-shake as soon as people import Integrations (and not even access one of the pluggable ones) because the spread operator (or in fact assigning an object) is a runtime operation. It's for the same reason we have BrowserTracing as a direct export and not under Integrations.

We need to do the same here - exporting the pluggable integrations top level.

[mydea]

right, that makes sense of course... I wonder actually if we should then completely get rid of the Integrations key and move all of these to the top level instead? 🤔 And then maybe suffix them with Integration or something like this...:

export { Dedupe as DedupeIntegration } from '@sentry/integrations';
// etc

IMHO it would be a bit weird to have the default integrations be available under Integrations and the pluggable ones directly at the root 😅

[lforst]

In the next major we should remove the Integrations object for sure. I agree having them in separate places is weird. I think we could export everything top level.

[mydea]

#8844