Continuous profiling not working with NextJS instrumentation

[austinwoon]

Getting no profiles in the APM section after setting the following configs to tracer on NextJS.

const appTracer = tracer.init({
  runtimeMetrics: true,
  logInjection: true,
  profiling: true,
})

Could I check if this is a bug or I have to enable something else on my end? Thank you.

[austinwoon]

Hey, after some debugging we found that the issue was that prebuilds were not being added in standalone mode in nextjs.

Have created a upstream fix here awaiting merge. Tagging maintainers as this is an actual bug that will prevent nextjs standalone users from using datadog profiling @rochdev @juan-fernandez

[rochdev]

Thank you for the upstream fix! Do you think this could be done in a more generic way? We have more native extensions than just profiling and we have more coming as well. Having to remember to update a list in an external project, while doable, is definitely not ideal.

[austinwoon]

Thank you for the upstream fix! Do you think this could be done in a more generic way? We have more native extensions than just profiling and we have more coming as well. Having to remember to update a list in an external project, while doable, is definitely not ideal.

To be honest, I'm not sure if this is a unique case because vercel has their own tree-shaking logic for standalone mode. Perhaps other bundlers have accounted for not treeshaking modules that require binaries somehow.

For this specific case, the most intuitive DX I could imagine that would not require too many changes on vercel's end would be to have them introduce a feature in the nft module that allows users to mark some modules to not be tree-shaken.

Then, your team could add some specific code snippets for users to include in next.config.js when using standalone mode to build.

This seems to be the best middleground without sprinkling moar AST magic 🧙 into their code haha (if you are interested, can have a look at vercel/nft#392, which was a fix for another module, this involved just hardcoding another way to handle imports which banked on the fact that node-gyp-build was imported in the parent folder)

Hope this makes sense!