sentry-javascript
sentry-javascript copied to clipboard
Support for Deno server
Summary
SDK For https://deno.land/
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 Status: Backlog or Status: In Progress, I will leave it alone ... forever!
"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. So, the following code works in browser :
import { default as Sentry } from 'https://dev.jspm.io/npm:@sentry/[email protected]';
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 :/ Ideas ? Thanks
@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!
the Node SDK has some default integrations that rely on node APIs
Yes, but I'm importing @sentry/browser, not @sentry/node π€
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!
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.
@KaKi87
Since Deno is also compatible with libraries supporting browsers, this code should also work on Deno, but it doesn't :/
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 os.uptime here https://github.com/denoland/deno/issues/17850.
It's coming :)
https://github.com/denoland/deno/pull/17179 https://github.com/denoland/deno_std/pull/3052
That works, thanks !
~~I'm still wondering why the browser SDK didn't work, though :thinking:~~
EDIT: actually, it works using npm:@sentry/node instead of a third-party transpiler.
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 ! Still looking forward to native Deno support though.
Just tried it with deno deploy and https://esm.sh/@sentry/[email protected] and got the following error:
Uncaught SyntaxError: The requested module '/v129/[email protected]/denonext/https-proxy-agent.mjs' does not provide an export named 'HttpsProxyAgent'
at https://esm.sh/v129/@sentry/[email protected]/denonext/node.mjs:8:6347
You need to go through npm: namespace, as it has different resolution algorithm.
Thanks it works π
I spoke too soon, it works locally, but in Deno Deploy I get
The deployment failed: Module not found "npm:@sentry/node".
It looks like
npm specifiers arenβt currently supported in Deploy, but will be soon.
Is there a workaround until then?
EDIT: It's indeed tracked here https://github.com/denoland/deploy_feedback/issues/314
This import map in my deno.json worked:
{
"lock": false,
"tasks": {
"start": "deno run --allow-net --allow-sys --allow-read --allow-env --watch server.ts"
},
"lint": {
"rules": {
"tags": ["recommended"]
}
},
"imports": {
"npm:@sentry/node": "https://esm.sh/@sentry/node?external=https-proxy-agent",
"https-proxy-agent": "https://deno.land/x/[email protected]/mod.ts",
"debug": "https://ga.jspm.io/npm:[email protected]/src/browser.js",
"http": "https://deno.land/x/http/mod.ts",
"socks": "https://esm.sh/[email protected]",
"net": "https://deno.land/x/net/src/mod.ts",
"assert": "https://deno.land/[email protected]/node/assert/strict.ts",
"dns": "https://deno.land/[email protected]/node/dns.ts",
"process": "https://deno.land/[email protected]/node/process.ts",
"stream": "https://deno.land/[email protected]/node/stream.ts",
"agent-base": "https://esm.sh/[email protected]",
"tls": "https://ga.jspm.io/npm:@jspm/[email protected]/nodelibs/browser/tls.js"
},
"scopes": {
"https://ga.jspm.io/": {
"@sentry-internal/tracing": "https://ga.jspm.io/npm:@sentry-internal/[email protected]/esm/index.js",
"@sentry/core": "https://ga.jspm.io/npm:@sentry/[email protected]/esm/index.js",
"@sentry/utils": "https://ga.jspm.io/npm:@sentry/[email protected]/esm/index.js",
"@sentry/utils/esm/buildPolyfills": "https://ga.jspm.io/npm:@sentry/[email protected]/esm/buildPolyfills/index.js",
"agent-base": "https://ga.jspm.io/npm:[email protected]/dist/src/index.js",
"async_hooks": "https://ga.jspm.io/npm:@jspm/[email protected]/nodelibs/browser/async_hooks.js",
"buffer": "https://ga.jspm.io/npm:@jspm/[email protected]/nodelibs/browser/buffer.js",
"child_process": "https://ga.jspm.io/npm:@jspm/[email protected]/nodelibs/browser/child_process.js",
"cookie": "https://ga.jspm.io/npm:[email protected]/index.js",
"debug": "https://ga.jspm.io/npm:[email protected]/src/browser.js",
"domain": "https://ga.jspm.io/npm:@jspm/[email protected]/nodelibs/browser/domain.js",
"events": "https://ga.jspm.io/npm:@jspm/[email protected]/nodelibs/browser/events.js",
"fs": "https://ga.jspm.io/npm:@jspm/[email protected]/nodelibs/browser/fs.js",
"http": "https://ga.jspm.io/npm:@jspm/[email protected]/nodelibs/browser/http.js",
"https": "https://ga.jspm.io/npm:@jspm/[email protected]/nodelibs/browser/https.js",
"lru_map": "https://ga.jspm.io/npm:[email protected]/lru.js",
"ms": "https://ga.jspm.io/npm:[email protected]/index.js",
"net": "https://ga.jspm.io/npm:@jspm/[email protected]/nodelibs/browser/net.js",
"os": "https://ga.jspm.io/npm:@jspm/[email protected]/nodelibs/browser/os.js",
"path": "https://ga.jspm.io/npm:@jspm/[email protected]/nodelibs/browser/path.js",
"process": "https://ga.jspm.io/npm:@jspm/[email protected]/nodelibs/browser/process.js",
"url": "https://ga.jspm.io/npm:@jspm/[email protected]/nodelibs/browser/url.js",
"util": "https://ga.jspm.io/npm:@jspm/[email protected]/nodelibs/browser/util.js",
"zlib": "https://ga.jspm.io/npm:@jspm/[email protected]/nodelibs/browser/zlib.js"
}
}
}
Seems to be working with Deno when using npm:@sentry/node. I don't see the point in doing anything else except documentation. Deno should be an option when onboarding a project, instead of choosing "Other". And there should be a page in the docs explaining to use npm:@sentry/node.
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 π
Bun is already supported, but as it's even more identical to NodeJS than 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).
https://twitter.com/DanielGri/status/1704496930364047855
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 π
Namespace is taken on the official registry: deno.land/x/sentry@deno
You should be able to contact [email protected] 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 npm specifiers.
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:
-
Deno doesn't appear to publish it's types to npm so I had to copy the 300KB
lib.deno.d.tsinto the package... -
The existing rollup config attempts to inject polyfills for things like optional chaining but Deno doesn't like them. Polyfills like this are not required for Deno since it supports modern js features
-
Deno doesn't appear to support resolving workspaces so
import { x } from '@sentry/core'is actually loading from npm rather than the local workspace during development.- For local development we probably need an import map that maps to the local paths?
- Once released to npm, Deno supports resolving via
package.json
-
Some
@sentry/nodedependencies@sentry/node > https-proxy-agent > debughave side-effects that accessprocess.envand cause Deno to prompt for env permissions- We should probably vendor all the Node SDK dependencies like
https-proxy-agenthttps://github.com/getsentry/sentry-javascript/issues/9199 - We don't need to use the Node SDK to ship an initial release of a Deno SDK. The browser integrations work.
- We should probably vendor all the Node SDK dependencies like
-
Consoleandfetchinstrumentation via monkey patching doesn't appear to work- I had this working in earlier versions of Deno so I guess there have been changes here?
- When I copy the instrumentation code into my Deno test entry point the monkey patching works. Maybe we can't mutate globals across module boundaries?
Maybe we can't mutate globals across module boundaries?
denoland/deno - feat(ext/node): properly segregate node globals #19307
This commit makes the globalThis of the entire runtime a semi-proxy.
This proxy returns a different set of globals depending on the caller's
mode. This is not a full proxy, because it is shadowed by "real"
properties on globalThis. This is done to avoid the overhead of a full
proxy for all globalThis operations.
The globals between Deno-mode and Node-mode are now properly segregated.
This means that code running in Deno-mode will not have access to Node's
globals, and vice versa. Deleting a managed global in Deno-mode will
NOT delete the corresponding global in Node-mode, and vice versa.