How can I keep /packages/replay-worker/examples/worker.min.js up-to-date in my codebase when it seems like it comes from an internal package?

[philwolstenholme]

#9409 looks very interesting! I'm trying to set it up on our codebase but not sure where to get the example worker from?

I can see it on Github at https://github.com/getsentry/sentry-javascript/blob/develop/packages/replay-worker/examples/worker.min.js but not sure how to install @sentry-internal/replay-worker myself to get access to that file from my codebase. The sentry-internal namespace makes me think that I might not be able to install it?

I'd like to write a npm postinstall hook that copies replay-worker/examples/worker.min.js into my public directory automatically so that my workerUrl is always pointing to the latest version.

I had a quick look in node_modules/@sentry/replay but couldn't find the file there either.

[billyvg]

Yeah, currently this is not published anywhere -- @mydea should we consider publishing this package to npm?

[bruno-garcia]

if so, could we have this versioned together with the main SDK? My concern is: How do we get people to update if we have a security or bug fix on it?

[mydea]

Not sure, users would still need to put this into their "public" folder somehow. IMHO either you should just copy-paste the file from the repo (what we recommend here https://docs.sentry.io/platforms/javascript/session-replay/configuration/#using-a-custom-compression-worker), or what the OP did, which is somehow configure a postinstall script or configure your bundler to serve this file as public, is also fine I guess! But this will depend a lot on the application setup.

[bruno-garcia]

the script is good, could we document that? I'm concerned about not having a way to let folks know they should update the worker

[philwolstenholme]

I've updated my postinstall script (and my comment below) to pass a 'silent' argument to curl and to skip running it if the CI env var is true (to avoid surprise updates outside of what is in the Git repo)

[bruno-garcia]

The script is a good solution and unblocks things. But I think Sentry should publish a new version on each release, and include the file hashes as we do for example here: https://release-registry.services.sentry.io/apps/sentry-cli/latest

We should then document such approach to download the latest version (while checking the SHA) and also appending a short version of the sha on the file name to allow cache busting.
Pointing to a static sample like that is also confusing because we make new releases on the repo and that file continues versioned from the release it came out:

[philwolstenholme]

I'm on Next.js so don't mind waiting if there is a plan for the Next SDK to do this sort of thing automatically :) But I can imagine some people might want to automate this recommendation from the PR and we'll need access to the file locally do to that:

Also note that when providing a custom worker, it is your own responsibility to keep it up to date - we try to keep the worker interface stable, and the worker is generally not updated often, but you should still check regularly when updating the SDK if the example worker has changed.

Another slight issue for @mydea I think – I noticed the example file has the SDK version number in a header – will that make it less cacheable as the cache will be busted each time the SDK version is updated, even if the worker file contents didn't actually change? Maybe there's something else you could put in that script header instead of the SDK version?

[mydea]

Hey there! You cannot use the file from the package, you have to copy the file and host it yourself. This is documented here:
https://docs.sentry.io/platforms/javascript/session-replay/configuration/#using-a-custom-compression-worker

The version is included in the file, but we only update the version when we actually update the worker script. So this will not change for each version, but you can easily see if the script has changed by comparing the version you have with the version in the repo :) Hope that helps!

(FWIW imho the process with a postinstall hook sounds decent to me! 👍 )

[philwolstenholme]

Ah that's great, I had naively assumed that the version in the example was not unique to the worker and was for a package like sentry-javascript as a whole.

[philwolstenholme]

Here's what I am doing to automate keeping the worker up to date, for anyone else interested. This assumes that you are keeping all your other Sentry dependencies up-to-date and that it's okay to always be using the example worker from Sentry's develop branch.

In package.json:

{
  "scripts": {
    "download-sentry-session-recorder-worker": "[ \"$CI\" = \"true\" ] || curl -s https://raw.githubusercontent.com/getsentry/sentry-javascript/develop/packages/replay-worker/examples/worker.min.js -o ./public/sentry-relay-recorder-worker.js",
    "postinstall": "patch-package && npm run download-sentry-session-recorder-worker"
  }
}

The curl command will not be executed if the environment CI has the value true. This is to avoid surprise updates during the CI process. You won't need this if you use npm's ignore-scripts option during your CI process.