size-limit report 📦

⚠️ Warning: Base artifact is not the latest one, because the latest workflow run is not done yet. This may lead to incorrect results. Try to re-run all tests to get up to date results.

View base workflow run

node-overhead report 🧳

Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.

View base workflow run

This pull request 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 apply the label PR: no-auto-close I will leave it alone ... forever!

FWIW I don't think we would need an own SDK for it. We somehow need to bring @sentry/nextjs and @sentry/cloudflare. The good thing of Vinext is, that it is working perfectly together with Cloudflare. So in theory we could wrap the entrypoint of wrangler.jsonc here: https://github.com/cloudflare/vinext/blob/adfc2236cba5f7cde63f32f6fb35c0d892428376/examples/app-router-cloudflare/worker/index.ts

And we could maybe just add a functionality in Cloudflare that we are reusing an existing client instead. So we could use instrument.ts as we would do for Next.js today and just reuse the client within Cloudflare and have the best of both worlds. This is ofc just a theory.

@JPeer264 That is what I tried initially, but there is no way (there is, but very high effort) it works. The internals are wildly different:

• Vinext doesn't emit OTEL telemetry at all, we rely on that in Next.js
• Vinext doesn't set the Next phase lifecycle env variables that we use to detect and make certain decisions:
  • Avoid creating spans during static generation.
  • Decide which runtime to use in instrumentation.ts (Not a problem in Vinext tho)
• Vinext doesn't support instrumentation-client.ts last time I checked, I need to see if they did recently or not.
• With Vinext, we have to wrap stuff with rollup and vite plugins, which is easy, but completely and wildly different from webpack and Turbopack.
• Our code relies on the detected version of Next.js since there is a bunch of hacks here that depend on it.
• Proxy instrumentation isn't supported last time I checked, will need to see if they added it or not yet.

I think it is still possible, but that would make the SDK so bloated, baking in vinext support into the next SDK means:

• Support a third bundler
• Assume a Next 16 version for this
• Maybe load it via workerd environment?
• We still need to detect which one the user is using, because both next and vinext can co-exist, and their guide tells them to build on top of a next app installation, we need to know which one the user is using to properly update the Next configuration and suspecquntly the vite.config.ts

@chargome will have better thoughts on this as well.

This pull request 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 apply the label PR: no-auto-close I will leave it alone ... forever!

Closing due to inactivity after stale warning. Comment or reopen when ready to continue, and use PR: no-auto-close to opt out of automatic closure.