feat(nextjs): Support cacheComponents on turbopack
#18304
Conversation
size-limit report 📦
|
chargome
changed the title
cacheComponentscacheComponents on turbopack
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.
|
| */ | ||
| function isCacheComponentContext(): boolean { | ||
| return process.env.NEXT_PHASE === 'phase-production-build'; | ||
| } |
There was a problem hiding this comment.
So right now now, all startSpan operations performed by users will be using the non-recording spans?
I suppose that means they can't manually instrument anything until the heuristic gets changed?
There was a problem hiding this comment.
This will be phase-production-build only during the build. During runtime tracing works as usual. Our tracing did not have any effect during build-time anyway since instrumentation.ts does not get registered – but we still ran into the uuid calls then
There was a problem hiding this comment.
Thanks, that makes a lot of sense 👍
| export { captureUnderscoreErrorException } from '../common/pages-router-instrumentation/_error'; | ||
|
|
||
| // Override core span methods with Next.js-specific implementations that support Cache Components | ||
| export { startSpan, startSpanManual, startInactiveSpan } from '../common/utils/nextSpan'; |
There was a problem hiding this comment.
A more robust change here might be to set a different acs for nextjs when you initialize the sdk server-side.
That means people can still use imports from @sentry/core or @sentry/node if they want, which might be useful for us.
There was a problem hiding this comment.
But we would not call init in this case (of a build)
|
@logaretm @AbhiPrasad I added a better check now to both verify that we're:
also updated the tests for these two scenarios |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
...packages/e2e-tests/test-applications/nextjs-16-cacheComponents/tests/cacheComponents.spec.ts
Outdated
Show resolved
Hide resolved
With this PR we stop breaking builds by simply re-exporting APIs that make use of synchronous random APIs:
startSpanstartSpanManualstartInactiveSpanWe do this with a naive approach of detecting a prod build phase and returning a noop span in cases where we call these APIs. We hope to get a more solid API for this from Vercel at some point so we can make this more bulletproof. The current version will also still emit a warning in webpack as the behaviour seems to change there.
This will only work for Turbopack as of now, as we still need to get rid of build time instrumentation in webpack in order for this to work.
closes #17895