Support for Deno server

Summary

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)

    - Handling imports/dependencies (imports & lack of package.json)

### Install
- [x] ```sentry@deno```
- [x] Publish on deno registry

### Product
- [x] Errors
- [x] Performance
- [x] Manual: Existing SDK API
- [x] Automatic: Expect to use existing HTTP, ORM, DB integrations for Node
- [x] Distributed Tracing: [Dynamic Sampling Context](https://develop.sentry.dev/sdk/performance/dynamic-sampling-context/) & Tracing without Performance
- [x] Event Context: Shall follow [Sentry SDK Spec](https://develop.sentry.dev/sdk/event-payloads/contexts/)

Open Points:

Are there any specific around transaction naming conventions or similar which would be natively better to Deno, than Node for example?
- Specifics around span operation naming conventions? (HTTP, DB, rpc, etc)

Namespace is taken on the official registry: https://deno.land/x/sentry@deno

@smeubank

@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

@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/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 :/
Ideas ?
Thanks

@KaKi87

@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

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.ts into 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/node dependencies @sentry/node > https-proxy-agent > debug have side-effects that access process.env and cause Deno to prompt for env permissions
- We should probably vendor all the Node SDK dependencies like https-proxy-agent Node SDK - Vendor dependencies #9199
- We don't need to use the Node SDK to ship an initial release of a Deno SDK. The browser integrations work.
Console and fetch instrumentation 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.

Deno doesn't appear to publish it's types to npm so I had to copy the 300KB lib.deno.d.ts into the package...

Turns out this is available from the cli via deno types > so this doesn't need to be kept in source control.

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 (npm:@sentry/core).

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 node16 resolution and we don't target that with the other packages (missing extensions, etc).

We can import the ESM JavaScript code (ie. ../../../core/esm/index.js) but these obviously don't export the types we need. I've tried referencing the types as per the docs but still get errors.

@timfish

@timfish Let's just bundle the SDK + dependencies into one file. There shouldn't be any issues with that besides typing for us to figure out. See #8780

Let's just bundle the SDK + dependencies into one file

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 console from the node scope like this but it feels a like fragile in the long term:
denoland/deno#20826 (comment)

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.

There is nothing mandating that the module is typescript to be published to deno.land

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 getsentry/sentry-deno repository that we push the build artifacts into specifically for publishing 🤔

https://deno.com/add_module

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 getsentry/sentry-deno repository that we push the build artifacts into specifically for publishing 🤔

Sounds like a plan to me!

@timfish

Thank you @timfish and @lforst for pushing this over the finish line! ❤️

@lforst

👀 https://deno.land/x/sentry@7.76.0

Big thanks to @lforst and @timfish for making it happen!

Navigation Menu

Repository navigation

Support for Deno server #3009

Summary

Open Points:

50 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Support for Deno server #3009

Description

Summary

Open Points:

Activity

gabeins commented on Sep 2, 2021

AbhiPrasad commented on Sep 30, 2021

github-actions commented on Oct 21, 2021

gabeins commented on Oct 21, 2021

KaKi87 commented on Feb 21, 2022

AbhiPrasad commented on Feb 23, 2022

KaKi87 commented on Feb 24, 2022

dgpgdev commented on May 9, 2022

50 remaining items

timfish commented on Oct 8, 2023

timfish commented on Oct 8, 2023

timfish commented on Oct 9, 2023

lforst commented on Oct 9, 2023

timfish commented on Oct 9, 2023

eliassjogreen commented on Oct 9, 2023

timfish commented on Oct 10, 2023

lforst commented on Oct 10, 2023

gabeins commented on Oct 12, 2023

AbhiPrasad commented on Oct 27, 2023

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions