Export Replay Compression Worker

[Spice-King]

Problem Statement

As per Sentry documentation, working around restrictive Content Security Policies (not allowing blobs in this case) asks one to manually download the worker script, stick it on the site somewhere, then toss a manually maintained link to it in the Sentry SDK config. Plus, then one would need to remember to update it from time to time. I think we can do better than the old school way of embedding JS dependencies.

Solution Brainstorm

Using Vite (I'll simply assume other bundlers offer ways to do so as well), they have documented ways to import the worker code and include it in the bundle.

Assuming that @sentry-internal/replay (which I did test as a bodge) was to export the worker script as @sentry-internal/replay/worker, the following code

import sentryWorkerUrl from "@sentry-internal/replay/worker?worker&url"

console.log(sentryWorkerUrl);
console.log(new URL("@sentry-internal/replay/worker", import.meta.url));

results in this (non-minified enabled) code

const sentryWorkerUrl = "/assets/sentry-Gn6g5N2F.js";

console.log(sentryWorkerUrl);
console.log(new URL("/assets/worker-DtGMygop.js", import.meta.url));

_{^{(Yea, I'm aware there are two copies of the worker, not a typo on my part, but what I'd call a bug in Vite/Rollup. One that's probably not worth fixing, as who is going to import the same worker script in two differing ways, never mind in the same file?)}}

Realistically, including a standalone copy in @sentry-internal/replay should not increase bandwidth usage for the package itself, as it should be compressed away, no one should miss the extra ~10.2 KB of disk space used in node_modules, and the compiled in version should get tree shaken out with the plugin like normal. It should be reexported from the @sentry/core package though, so people are not digging around in internal packages for it.

Broadening the type of ReplayConfiguration['workerUrl'] to string | URL would be a nice bonus too, if only to avoid needing to call .toString() on the URL object. As there is zero processing on the workerUrl property right now, other than passing it around and checking if undefined, the types could be just expanded with no logic changes, since the Worker constructor accepts URLs anyway. It could be typed to ConstructorParameters<typeof Worker>[0] if you want to be fancy TypeScript wizard and allow what ever comes down the ECMAScript pipe for workers, but that's also far more verbose than just manually writing out string | URL.

Sentry's documentation would need a light touch up to mention that the export exists, with a call out that it depends on one's bundler which one should read it's documentation for, and possibly even marking it be the recommended way of doing it (provided the user's bundler supports it). The current way should remain documented, since some bundlers might not support it and there might still be people who are not even using a bundler.

[mydea]

Hey, thanks for writing in.
Generally, this script does not really change much, so it should be pretty safe to just inline it. The last actual change (that was not just docs etc.) to this was in November 2023 :D

The reason we did not put anything was, as you've mentioned basically, that this is pretty bundler-specific as you cannot just import it. I am a bit hesistant to expose this directly because I fear people will accidentally misuse it 😬 also, people would have to depend explicitly on @sentry-internal/replay which is also something we don't really want 🤔

That being said, I guess we could expose this as a sub-path export, then at least it is there. we can still think about how to document this in a non-confusing way. PRs are welcome, if you want to give it a try!