feat(loader): Allow to configure 'window.sentryOnLoad'

[mydea]

Allow to configure a new window.sentryOnLoad callback, which can be defined before the Loader Script is loaded, thus allowing to streamline timing issues & prevent issues if e.g. the loader script was not loaded.

tests added here getsentry/sentry-javascript#9331

Closes #58428

[github-actions]

🚨 Warning: This pull request contains Frontend and Backend changes!

It's discouraged to make changes to Sentry's Frontend and Backend in a single pull request. The Frontend and Backend are not atomically deployed. If the changes are interdependent of each other, they must be separated into two pull requests and be made forward or backwards compatible, such that the Backend or Frontend can be safely deployed independently.

Have questions? Please ask in the #discuss-dev-infra channel.

[lforst]

I think it might make sense to make sentryOnLoad an array of callbacks because you might want to add callbacks in many different places in your code?

[mydea]

Really this should only be used to call Sentry.init(), which you should only do once in your code. because otherwise you will/may again have race conditions, think:

window.sentryOnLoad = window.sentryOnLoad || [];
window.sentryOnLoad.push(function() {
  Sentry.captureException('xxx');
});

// somewhere else
window.sentryOnLoad = window.sentryOnLoad || [];
window.sentryOnLoad.push(function() {
  Sentry.init(customConfig);
});

You'll have no way to ensure that the correct init is called.

IMHO for such scenarios it would be better to:

1. define your custom init only in window.sentryOnLoad
2. Use Sentry.onLoad for the other stuff, as we can then ensure this is called after window.sentryOnLoad (you'll still have to guard in this case for window.Sentry && window.Sentry.onLoad(), but IMHO this is fine, as this is more of an edge case - generally you should stick to the loader public APIs when using the loader anyhow 😅

[codecov]

Codecov Report

Merging #58574 (0b46d7b) into master (71890e0) will decrease coverage by 0.01%.
Report is 5 commits behind head on master.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master   #58574      +/-   ##
==========================================
- Coverage   80.67%   80.67%   -0.01%     
==========================================
  Files        5160     5160              
  Lines      226364   226359       -5     
  Branches    38139    38138       -1     
==========================================
- Hits       182624   182607      -17     
- Misses      38163    38174      +11     
- Partials     5577     5578       +1     

Files	Coverage Δ
...try/api/endpoints/organization_release_assemble.py	84.78% <100.00%> (-1.50%)	⬇️
static/app/components/sidebar/index.tsx	91.66% <ø> (ø)
...views/alerts/rules/metric/triggers/chart/index.tsx	81.03% <ø> (ø)
static/app/views/alerts/rules/metric/types.tsx	100.00% <ø> (ø)

... and 6 files with indirect coverage changes

[lforst]

convinced!