ref(replay): Extract worker into @sentry-internal/replay-worker

[mydea]

Currently, we have multiple rollup jobs in @sentry/replay, one for the worker (which is needed even at dev time), and one for the actual replay package. This is not ideal and leads to the build behaving differently from other packages.

This PR extracts the worker into a @sentry-internal/replay-worker package, which is private (=not published to NPM). It builds a single file, which is the worker in string form (plus a type file). Then, in @sentry/replay we can simply consume this package.

The main downside is that we have another package, but I believe that it is worth it for clarity in this case.

I have checked e.g. the @sentry-internal/node-integration-tests package as comparison, and it seems I don't need to do anything but set private: true in package.json to ensure we do not publish this anywhere? Let me know if that's not correct 😅

Closes #6371

[github-actions]

size-limit report 📦

Path	Size
@sentry/browser - ES5 CDN Bundle (gzipped + minified)	19.84 KB (-0.01% 🔽)
@sentry/browser - ES5 CDN Bundle (minified)	61.45 KB (0%)
@sentry/browser - ES6 CDN Bundle (gzipped + minified)	18.62 KB (+0.02% 🔺)
@sentry/browser - ES6 CDN Bundle (minified)	54.99 KB (0%)
@sentry/browser - Webpack (gzipped + minified)	20.39 KB (0%)
@sentry/browser - Webpack (minified)	66.63 KB (0%)
@sentry/react - Webpack (gzipped + minified)	20.41 KB (0%)
@sentry/nextjs Client - Webpack (gzipped + minified)	47.66 KB (0%)
@sentry/browser + @sentry/tracing - ES5 CDN Bundle (gzipped + minified)	26.82 KB (+0.02% 🔺)
@sentry/browser + @sentry/tracing - ES6 CDN Bundle (gzipped + minified)	25.25 KB (-0.01% 🔽)
@sentry/replay ES6 CDN Bundle (gzipped + minified)	42.99 KB (-0.01% 🔽)
@sentry/replay - Webpack (gzipped + minified)	38.24 KB (0%)

[lforst]

Instead of creating an entirely new package could we instead clean this worker thing up as a whole?:

• Not putting the worker in a string but let it be a real and exported function.
• Importing the function and doing toString (sorta like they're doing here)

[mydea]

Instead of creating an entirely new package could we instead clean this worker thing up as a whole?:

• Not putting the worker in a string but let it be a real and exported function.
• Importing the function and doing toString (sorta like they're doing here)

The problem with that is that we need the function to be transpiled, as it will be loaded as-is.

I've explored ways to make it work with actually importing the module (not as a string), but so far found no way to make this work with jsdom, sadly :( I'll give it another try, we changed a few build things, but my hopes are slim.

[billyvg]

Note that we may even want to publish this to the CDN so that we can load the worker from a remote url. We have users that cannot use the worker due to CSP (can't load blobs).

[mydea]

Note that we may even want to publish this to the CDN so that we can load the worker from a remote url. We have users that cannot use the worker due to CSP (can't load blobs).

Yeah, that's also a thought I had, but this will also probably not be OK for other users (who do not want/can load stuff from external URLs outside of their direct control). So this would need to be an opt-in thing, I guess.

FYI I've also explored various other ways to inline workers with rollup, but none of them worked so far (the nice ones are esm only, and do not support cjs. others are not supported by jest/jsdom, ...)

[billyvg]

Yeah, that's also a thought I had, but this will also probably not be OK for other users (who do not want/can load stuff from external URLs outside of their direct control). So this would need to be an opt-in thing, I guess.

Yeah I think opt-in, but I think users would be willing to allow our CDN host sooner than allowing blobs.

[billyvg]

I'm 👍 on merging this -- currently we don't have automation to ensure that our worker bundle is not stale. If you modify the worker, you would need to build and commit the worker bundle.

[mydea]

Closes in favor of #7139