feat(nextjs): Add Edge Runtime SDK

[lforst]

Ref: #4206

This PR adds a very small SDK that is exported by @sentry/nexts which is capable of running on the Vercel Edge Runtime.

The errors that are captured through this SDK are still very barebones and we have no way of source mapping yet (we don't even know if it is possible).

Testing this change is impossible with our current setup. I will create proper E2E tests when #6746 is merged

[github-actions]

size-limit report 📦

Path	Size
@sentry/browser - ES5 CDN Bundle (gzipped + minified)	19.84 KB (-0.01% 🔽)
@sentry/browser - ES5 CDN Bundle (minified)	61.46 KB (0%)
@sentry/browser - ES6 CDN Bundle (gzipped + minified)	18.62 KB (+0.01% 🔺)
@sentry/browser - ES6 CDN Bundle (minified)	55 KB (0%)
@sentry/browser - Webpack (gzipped + minified)	20.38 KB (0%)
@sentry/browser - Webpack (minified)	66.55 KB (0%)
@sentry/react - Webpack (gzipped + minified)	20.4 KB (0%)
@sentry/nextjs Client - Webpack (gzipped + minified)	47.63 KB (0%)
@sentry/browser + @sentry/tracing - ES5 CDN Bundle (gzipped + minified)	26.82 KB (+0.02% 🔺)
@sentry/browser + @sentry/tracing - ES6 CDN Bundle (gzipped + minified)	25.25 KB (-0.02% 🔽)
@sentry/replay ES6 CDN Bundle (gzipped + minified)	43.26 KB (-0.01% 🔽)
@sentry/replay - Webpack (gzipped + minified)	38.5 KB (0%)

[AbhiPrasad]

h: can we get some unit tests? we can just copy the one's we have in node.

focus should be one
a) the transport
b) _prepareEvent call in the client (since that sets a edge runtime that is different)

[AbhiPrasad]

In the future we can include RequestData and LinkedErrors here since they are agnostic to node, but that requires some more refactoring.

[lforst]

LinkedErrors could probably even live in @sentry/core. We currently duplicate it in browser & node. As for RequestData I am a bit unsure. That integration has become a bit of a behemoth and I don't like it becoming even more generic.

[AbhiPrasad]

We currently duplicate it in browser & node

There is slightly different behaviour for node/browser 😅

RequestData being overloaded is fair, we can probably re-examine this.

[AbhiPrasad]

CI is 3 fast 5 me

[Lms24]

Wow, amazing work man!
Just checked: For SvelteKit, users can also opt-in to use edge: https://github.com/sveltejs/kit/tree/master/packages/adapter-vercel

Just wondering if it makes sense to proactively put this SDK into its own package so we could use it from a potential SvelteKit SDK in the future. WDYT?
Although, if I'm not mistaken we should be able to do this in a non-breaking way in the future, right? In that case let's just leave it as is for now.

[AbhiPrasad]

Just wondering if it makes sense to proactively put this SDK into its own package so we could use it from a potential SvelteKit SDK in the future

we can extract into another package at any time in the future, so let's leave it till we absolutely need it. For now we leave it in here.

[lforst]

Just checked: For SvelteKit, users can also opt-in to use edge: sveltejs/kit@master/packages/adapter-vercel

Nice to know! I guess we have some experience now on how to tackle this!

Just wondering if it makes sense to proactively put this SDK into its own package so we could use it from a potential SvelteKit SDK in the future. WDYT? Although, if I'm not mistaken we should be able to do this in a non-breaking way in the future, right? In that case let's just leave it as is for now.

Yes, we can move everything into its own package afterward without breaking things. I agree with the idea of only doing this though when we get to it!

[AbhiPrasad]

Just checked: For SvelteKit, users can also opt-in to use edge

The same applies for Remix: https://github.com/remix-run/remix/tree/main/packages/remix-vercel 😄