Support for Deno server #3009
Comments
|
Namespace is taken on the official registry: https://deno.land/x/sentry@deno |
|
@smeubank Something we should consider as part of work in the future - building out an SDK for Deno. |
|
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 "A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀 |
|
@AbhiPrasad @smeubank would love to see an official Deno SDK… 🙏 |
|
NPM libraries that support browsers can usually be imported as ES modules thanks to JSPM. import { default as Sentry } from 'https://dev.jspm.io/npm:@sentry/browser@6.17.9';
Sentry.init({ dsn });
Sentry.captureException(new Error('Hello, World !'));Since Deno is also compatible with libraries supporting browsers, this code should also work on Deno, but it doesn't :/ |
|
@KaKi87 It might be because the Node SDK has some default integrations that rely on node APIs - but that's just a guess of mine. We rely on comments/emoji reactions for GH issues like these to determine what to work on, so please continue to let us know that this is important to you all! |
Yes, but I'm importing
Done 👍 |
|
i'm looking forward this sdk release |
|
I've been actively looking at what changes are required to support other runtimes like Deno with the existing codebase! Until all those changes are complete, I made this experimental Deno client. |
There's one missing API. For now, you can easily work around it with: import * as Sentry from "npm:@sentry/node";
Sentry.init({
dsn: "__PUBLIC_DSN__",
integrations: [
new Sentry.Integrations.Context({
app: true,
os: true,
device: false, // notice `device` context is off due to missing `os.uptime` API
culture: true
})
]
});You can track the progress of |
|
It's coming :) |
|
That works, thanks !
|
|
With the release of Deno 1.30, our Node SDK should work out-of-the-box now. Would love someone to give it a try and report back if they have any issues! :) import * as Sentry from "npm:@sentry/node"
Sentry.init({
dsn: "__PUBLIC_DSN__"
}) |
|
Confirmed, thanks ! |
|
Just tried it with deno deploy and |
|
I disagree, because even though relying on Deno's support for Node works, it's still suboptimal in terms of performance and size on the Deno end, and in terms of metadata in Sentry's end, as it's full of fake Node metadata and lacking Deno metadata. Additionally, it doesn't support the "Deno has panicked" error. Thanks |
|
@KaKi87 What would you suggest be done aside from rewriting the whole library? |
|
If that's what was done for Node, then Deno deserves the same work. |
|
Not sure if this issue covers it, but it would be nice too if Deno was among the list of platforms in Sentry for new projects. For some reason Bun is already supported, but as it's even more identical to NodeJS than Deno, I was a but suprised to see that but not Deno 😅
|
Yes, because Bun was made specifically to replace Node, while Deno is something else entirely, and closer to browser if anything, but more importantly with its own APIs. |
|
After the Bun support announcement on X/Twitter, there was a soft commitment to take another look at Deno support in Sentry by @HazAT (with some interest shown by both CEO and CTO of Sentry).
I'm confident it can be a first class integration/support as good as the Node one. Let's just hope it can get prioritized soon 🙏 |
You should be able to contact modules@deno.com and gain access to the name as it seems like it isn't maintained and hasn't been updated for 3+ years. |
|
Hey folks! We do have this on next up on our todo list, we're just finishing up some work we did for automatically detecting ANR/event loop stalls for Node.js and Electron. The ANR feature allows us to detect when the event loop has been blocked for 5+ seconds and generate a stacktrace that points to the line of code causing the block - which means it can be a little complicated to get figured out, hence why we need some extra time there. Once that is in a good state, we'll move on to Deno! |
|
Shortly after v1 and before npm support, I created an experimental SDK by converting the existing Sentry code to Deno import syntax. This weekend I spent a couple of hours working on a branch that adds a Deno SDK using We can publish to npm and users can import via: import * as Sentry from 'npm:@sentry/deno';I thought I'd brain-dump my notes here in case anyone subscribed to this issue can offer advice:
|
denoland/deno - feat(ext/node): properly segregate node globals #19307 |
Turns out this is available from the cli via Rather than creating a Deno SDK as an npm module, I have also tried creating it as a pure Deno module that pulls in the Sentry dependencies using npm specifiers ( This works but I can't work out how to load the local workspace packages (types/core/utils/etc) for local testing. There's no point having the Deno SDK in the JavaScript repository if we can't test it against changes to it's dependencies. We can't import the TypeScript files directly because Deno only supports We can import the ESM JavaScript code (ie. |
We would be able to publish this to npm, but not to deno.land since that requires that modules are in TypeScript. It looks like we can access the deno global to instrument |
|
There is nothing mandating that the module is typescript to be published to deno.land, I would suggest you publish it there as JS if that is what makes sense and then reference the typings using the deno (or typescript) type reference comments. |
Thanks, that's helpful info! I think the limiting factor might be that we're planning to bundle the code and deno.land expects the source files to be stored in the repository. We could add a 
|
Sounds like a plan to me! |
Summary
SDK For https://deno.land/
A Deno SDK would require Sentry provides a package which follows the spec upon which Deno applications are built. Essentially it is based on a non-node JS runtime. To some extend the existing JS SDK can already run in such runtimes with recent changes post v7 (Vercel Edge for example)
Install
Product
Open Points:
The text was updated successfully, but these errors were encountered: