PlasmoHQ
feat(with-sentry): update with-sentry examples to align with shared environments
I went through a lot of variations when upgrading/using Sentry in extensions.
While Sentry does provide guidance when it comes to shared environments, recommending v8, this guidance really only applies to code executed in the content scripts. This is because content scripts are the only thing executed in the same window as the website currently in the browser.
But, what I found out the hard way is that even using Sentry's default way of initialising in the popup script can cause issues, specifically, rejections from the stores.
Violation: Including remotely-hosted code in a Manifest V3 item.
With this code snippet being the one in question.
Code snippet: popup.cc3817b7.js: " let u = function(e) { let t = (0, o.getClient)(), r = t && t.getOptions(), n = r && r.cdnBaseUrl || "https://browser.sentry-cdn.com/"; return new URL(`/${(0,o.SDK_VERSION)}/${e}.min.js`, n).toString() }(r), c = (0, s.WINDOW).document.createElement("script"); c.src = u, c.crossOrigin = "anonymous", c.referrerPolicy = "origin", t && c.setAttribute("nonce", t); let p = new Promise((e, t) => { c.addEventListener("load", () => e()), c.addEventListener("error", t) }), d = s.WINDOW.document.currentScript,"
After a deep-dive, this code is included when using the Sentry.init function. This is because of how the import works (e.g. import * as Sentry from '@sentry/browser [or from the react version]), as it actually imports all things, which includes the lazy loading integration [this integration isn't needed when you're bundling code, but hey ho).
I've modified the example to show how to set up Sentry for usage in a content script, which shouldn't have this problem, but I've left the popup initialisation as standard with a comment. Open for discussion!
@louisgv I've updated this PR. If you wouldn't mind giving it a final review and merging if you see fit