-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Support different JS runtimes #5611
Comments
This comment was marked as outdated.
This comment was marked as outdated.
The first step in supporting other runtimes is getting
At this point, However, To rectify this, all runtime specific code should be moved to the runtime packages:
The above can done without technically making breaking changes since we make no guarantees about The major downside to moving these utilities to the browser/node packages and exporting them at the root is that they would become public API methods (for downstream SDKs to use) and with that comes stability guarantees. It would be less of a maintenance headache to either:
|
- Replaces `getGlobalObject` global object detection with a modern implementation taken from `core-js` which is then modified/simplified a little - Prioritises `globalThis` which was previously removed due to requiring a TypeScript version which was required in a no longer supported version of Angular (#2978) - This is a requirement for future support of other js runtimes (#5611) - No longer uses `isNodeEnv` 🎉 - Caches the global so it doesn't need to be evaluated for every invocation of `getGlobalObject`
Shouldn't it be Also, I'd just have all tracing functionality in |
Yep, I need to update the above ramblings. There's a more recent issue for the tracing changes.
Would we want to add all the hub extensions by default too? We wouldn't want to run |
Continued thread over in more recent issue here: #5815 (comment) |
We had a discussion internally about the global object changes - @timfish could we look into if we can just use |
Eventually, but we'll need to wait for Node.js v12 to be our MSV. And the Sentry supported browsers suggests we need to support Android 4.4 and IE10/11 so these would need to be polyfilled. That means we can probably remove the sentry-javascript/packages/utils/src/global.ts Lines 56 to 65 in 8570f0d
|
LOL Looks like we haven't updated this page in quite a long time. (EDIT: Heh. Turns out July-me already discovered that: getsentry/sentry-docs#5351) I can say for sure we don't need to worry about Android 4.4. I did a quick google, and the first version which can handle, for example, object spread is Android 8. For IE11, we've already told people that they have to use one of our ES5 bundles, to which we could add a polyfill if necessary. But the Node 10 business is definitely a bigger blocker. I like your idea of at least removing the browser-specific parts. |
I’m using Remix with Cloudflare Workers. It would be great if there is support for this. There is this package that everyone uses when using Cloudflare Workers, it might be a good starting point to start work on Cloudflare Workers runtime. |
I realised I didn’t post cross-post here last time—I have a pretty hacky solution for Cloudflare Workers with Toucan. |
🤞 for Cloudflare Pages support, which should be nearly identical to Cloudflare Workers, just with different handlers. |
@KrisBraun Gonna happen soon™ 👀 |
I’ve updated my Cloudflare Workers Gist for Toucan v3.2.0 and Remix v2. It’s a lot more complicated & hacky now thanks to Remix v2, but still very possible. Please reply there if you have any questions :) |
Now we've dropped Nove v12 we can simplify to `globalThis`: #5611 (comment)
Now we've dropped Nove v12 we can simplify to `globalThis`: getsentry#5611 (comment)
With The one's left on the list are: but right now these are not high priority for us. We'll tackle them slowly over the next couple quarters (PRs are always welcome though!) |
Problem Statement
The Sentry SDK should work with WinterCG-compatible runtimes other than NodeJS. We should build new SDKs for these platforms, or figure out how to adapt our Node SDK to fit them.
The spec: https://github.com/wintercg/proposal-common-minimum-api
There are also other JS runtimes we can take a look at:
Solution Brainstorm
If you are interested in this, please comment on the individual issues linked above!
The text was updated successfully, but these errors were encountered: