Bundling with @sentry/profiling-node@8.49.0 no longer outputs `.node` files, 8.47.0 does

[rgripper]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/node

SDK Version

8.39.0

Framework Version

No response

Link to Sentry event

No response

Reproduction Example/SDK Setup

No response

Steps to Reproduce

@sentry/profiling-node@8.49.0
esbuild (or bun) no longer outputs *.node binaries with my instrument.js using

  loader: {
    // ensures .node binaries are copied to ./dist
    ".node": "copy",
  },

But @sentry/profiling-node@8.47.0 works fine

Expected Result

the output folder contains multiple *.node binaries and instrument.js

Actual Result

the output folder contains only instrument.js

[s1gr1d]

Hello, thanks for reaching out! This bug was most likely introduced in this PR: #14952
I was able to reproduce it and we're on it to fix this!

For now, you can downgrade to 8.48.0 or try to copy the node binaries from node_modules/@sentry/profiling-node/lib

[s1gr1d]

For more context: esbuild does not support createRequire and there is an open issue for this: evanw/esbuild#1828

As node-based libraries were not instrumented with Sentry correctly when using them together with profiling, this PR was added to fix this: #14470 (released with 8.49.0).
This PR basically removes storing require etc. on globalThis as this was the root-cause of a set of problems. However, storing those variables on globalThis is also one of the proposed short-term solutions in esbuild to support ESM and CJS: evanw/esbuild#1921 (comment)

[timfish]

To make native module loading compatible with more bundlers you can ensure you always do the loading in a CJS context with require:

load.cjs

function loadBindings() {
  // simplified 😂
  return require('./path/to/module.node');
}
exports.loadBindings;

Since ESM can load CJS, you can just do this in ESM:
integration.mjs

import { loadBindings } from './load.cjs';

CJS can just load the CJS:
integration.cjs

const { loadBindings } = require('./load.cjs');

[zachelrath]

@s1gr1d @timfish Will a fix for this be backported to 8.x ? Or maybe I'm not understanding how to apply the fix in my environment. I'm still seeing this issue on 8.52.1

We're using @sentry/nextjs in our Next.js project along with @sentry/profiling-node, and we are importing the Node profiling integration in sentry.server.config.ts like this:

import { init, postgresIntegration } from "@sentry/nextjs";
import { nodeProfilingIntegration } from "@sentry/profiling-node";

init({
	...
	integrations: [
		postgresIntegration(),
		nodeProfilingIntegration(),
	],
});

When I do a regular npm install, and run next dev, the expected .node binaries are all present in node_modules/@sentry/profiling-node/lib.

However, when I do a Next.js production build with next build, the lib folder doesn't contain any of the expected binaries, so the Node profiling integration fails to locate the expected binaries at runtime and crashes the app.

I've confirmed that this behavior started with 8.49.0 (binaries are present in lib on <= 8.48.0), and it is still happening on 8.51.2

Thank you!

[timfish]

This is currently fixed only in v9. The changes are quite large so I'm not sure how easy this would be to backport to v8.