Skip to content

Allow to define pluggable integrations for loader #47540

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
mydea opened this issue Apr 18, 2023 · 2 comments
Closed

Allow to define pluggable integrations for loader #47540

mydea opened this issue Apr 18, 2023 · 2 comments

Comments

@mydea
Copy link
Member

mydea commented Apr 18, 2023

Problem Statement

Currently, when using the loader, the only way to get pluggable integrations working is to load them in addition to the loader script from the CDN.

However, this is brittle, because for the CDN you'll have to define an exact version, while the loader will always load the latest SDK version. This can lead to the case where the integration version becomes incompatible with the main SDK version, as we generally assume these are in sync.

See also getsentry/sentry-javascript#2476 (comment)

Solution Brainstorm

We should allow a way to define integrations to load for the loader. For example, something like this:

<script src="https://loader-url.com" data-integrations="HttpClient,CaptureConsole"></script>

We could then make sure to load the correct version of the integration in the loader script.

@andreyvolokitin
Copy link

Also note that currently lazy-loading and avoiding sentry scripts being ad-blocked is problematic due to inability to set SDK bundle url: getsentry/sentry-javascript#7288. Regular sentry CDN urls can be blocked by ad-blocker thus preventing SDK to load. This can be solved by serving SDK from the own host or using reverse proxy to change URL, e.g myproxy.com/?url=sentry-cdn.com/bundle.js. But for this we need an ability to pass the URL to the loader. Currently at my company we solve this by reverse proxy which rewrites JS urls inside JS files (so we "pass" our URL to the loader by replacing it inside the loader.js on the fly)

I guess loading integrations by the loader might further complicate this, as there will be more urls to handle (and those additional urls might be dynamically built preventing them to be replaced by reverse proxy as we currently do). I currently have no idea how this could be handled, but I guess again via some data-attribute on a loader <script> tag

@github-actions
Copy link
Contributor

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!


"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

@github-actions github-actions bot locked and limited conversation to collaborators Jun 1, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants