fix(browser): update Request checks to be valid in Deno

[GJZwiers]

In Deno @sentry/browser is almost usable, but the check new Request('') fails silently because Deno throws a TypeError: invalid URL that goes to a catch block. This changes the Request call to include a valid URL http://www.example.com so that @sentry/browser can be imported in Deno without this issue.

[AbhiPrasad]

Hey @GJZwiers, thanks for the contribution! How are you using Sentry with deno?

[GJZwiers]

Hey @GJZwiers, thanks for the contribution! How are you using Sentry with deno?

Hello! Recently I tried to port the browser package to Deno, which works well enough for sending events to Sentry (but it's difficult to maintain for me). A lot of Deno users also use CDNs to import code, for example there is another Sentry port in the making. But in the next release of Deno there will be more support for importing npm packages, which will look something like this:

import * as Sentry from 'npm:@sentry/browser';

I believe most of the browser APIs used in sentry are now also supported in Deno, so I think it should be possible, maybe with a few small tweaks, to use Sentry in Deno this way.

[AbhiPrasad]

Awesome, this sounds reasonable to me, cc @timfish

[timfish]

I've just had a chance to try out the Deno support for npm packages. It looks like npm packages support currently requires the --unstable flag so the behaviour is likely to improve/change over time.

Whereas @sentry/browser might be usable at some point, there are still outstanding issues:

• Merely referencing process in @sentry/utils causes some node shims to be automatically imported which then prompt for access to the NODE_DEBUG environment variable. There's currently no way to prevent this
• If I enable debug: true I get Uncaught TypeError: Cannot read properties of undefined (reading 'log') from @sentry/utils logger/consoleSandbox
• I haven't managed to get the npm browser package to send events to Sentry from Deno yet

There are also some other key features which I suspect will always need to be specifically coded for Deno:

• Support for sending unhandled error events due to the aggressive way Deno closes the process. The only way I've got these to send reliably is to call event.preventDefault() and then rethrow the error after flushing is complete
• Stack trace file path normalisation which can be particularly tricky due to Denos default of no filesystem access
• Deno specific context