feat(browser): Disable client when browser extension is detected in init()#16354
feat(browser): Disable client when browser extension is detected in init()#16354
init()#16354Conversation
size-limit report 📦
|
a0318d8 to
a7c890c
Compare
57bd5b7 to
76473ae
Compare
|
Before, we were just no-oping when a browser extension was detected. Is there any use case for having a client running, even though it's a browser extension and Sentry should not be set up there? |
No, it is not a big difference in practice, nothing will be instrumented and nothing will be sent. It is a subtle difference really, you'll have |
There was a problem hiding this comment.
Ok I think my previous question was already asked and answered (sorry, missed the convo initially) 😅
can we just make sure to change the PR title? because it reads like the client would disable itself in general when detecting the extension but in fact, it just does that when created via init.
Agree btw that it's okay to always return a client instance
init()
|
makes sense, I renamed the PR! 👍 |
76473ae to
0eb6c5f
Compare
Similar to #16353, this changes how default options for BrowserClient are handled. Instead of building this in
init, we now do (some) of it in BrowserClient.Additionally, this also adjusts what we do if we detect a browser extension: Instead of skipping the setup, we now just disable the client. This streamlines this a bit and also ensures that we actually always return a
Clientfrom init.It also fixes the type for
BrowserOptionto actually allow to configurecdnBaseUrl, which was actually only set for the ClientOptions, oops.The reason for this is to streamline the
initcode, making it easier to extend/adjust it. Right now, there is a lot going on in different places there. By moving as much as we can (and makes sense) toBrowserClientthis becomes a bit easier. While playing with different ways to handle the browser extension stuff, I ended up landing on just disabling the SDK in this scenario.