You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/platforms/javascript/common/best-practices/shared-environments.mdx
+37-10
Original file line number
Diff line number
Diff line change
@@ -39,16 +39,18 @@ These best practices are relevant for you if you set up Sentry in one of the fol
39
39
- Libraries
40
40
- Any other scenario where you might have multiple Sentry instances running in the same environment
41
41
42
-
<Note>
42
+
<Alertlevel="danger">
43
43
44
44
When setting up Sentry in a shared environment where multiple Sentry instances may run, you should **not use `Sentry.init()`**, as this will pollute the global state. If your browser extension uses `Sentry.init()`, and a website also uses Sentry, the extension may send events to the website's Sentry project, or vice versa.
45
45
46
-
</ Note>
46
+
</ Alert>
47
47
48
-
For such scenarios, you have to set up a client manually as seen in the example below.
49
-
In addition, you should also avoid adding any integrations that use global state, like `Breadcrumbs` or `GlobalHandlers`. Furthermore, some default integrations that use the global state have to be filtered as in the example below.
50
-
As a rule of thumb, it's best to avoid using any integrations and to rely on manual capture of errors only in such scenarios.
48
+
## Shared Environment Setup
51
49
50
+
For the use cases listed above, set up a client manually as seen in the example below.
51
+
In addition, avoid adding any integrations that use global state, like `Breadcrumbs` or `GlobalHandlers`.
52
+
Furthermore, some default integrations that use the global state have to be filtered as in the example below.
53
+
In these scenarios, it's a best practice to avoid using any integrations and to rely on manually capturing errors.
52
54
53
55
```javascript
54
56
import {
@@ -61,11 +63,9 @@ import {
61
63
62
64
// filter integrations that use the global variable
@@ -104,3 +104,30 @@ If you notice that Sentry is not capturing error events from the browser extensi
104
104
You can disable that by going to your **Project Settings > Inbound Filters** and disabling filtering out errors known to be caused by browser extensions.
105
105
106
106
Read more about Inbound Filters in the product documentation under [Inbound filters](/concepts/data-management/filtering/#inbound-data-filters).
107
+
108
+
## Skipping the Browser Extension Check
109
+
110
+
_Available in all browser-based SDKs since version `8.37.0`_
111
+
112
+
If for some reason, the SDK wrongfully detects that it's initialized in a browser extension, you can skip the check by specifying the `skipBrowserExtensionCheck` option when initializing the SDK:
113
+
114
+
```javascript
115
+
import*asSentryfrom"@sentry/browser";
116
+
117
+
Sentry.init({
118
+
dsn:"___PUBLIC_DSN___",
119
+
skipBrowserExtensionCheck:true,
120
+
// ...
121
+
});
122
+
```
123
+
124
+
<Alertlevel="danger">
125
+
126
+
You shouldn't use this option if you're in fact using the SDK in a browser extension or another shared environment.
127
+
Initializing the SDK via `Sentry.init` has no advantages over manually setting up the client and scope as described on this page.
128
+
You'd risk quota increases with unactionable issues, interference with other Sentry SDKs, and data leakage by doing so.
129
+
130
+
</Alert>
131
+
132
+
This option is purely meant as an escape hatch if our browser extension check is incorrectly detecting a browser extension.
133
+
An example for this might be a cross-platform application framework that exposes similar global APIs like browser extensions.
0 commit comments