esbuild-plugin overrides injected variables

[ilijapuaca]

Environment

What version are you running? Etc.

@sentry/[email protected], [email protected]

Steps to Reproduce

This surfaced after upgrading to esbuild 0.19.0, but perhaps more widely spread and related to this issue?

When @sentry/esbuild-plugin is used, the built bundle would crash with ReferenceError: process is not defined when run. I spent some time comparing the output with and without Sentry plugin, here's the minimal repro setup:

build-config/build.js

import {sentryEsbuildPlugin} from '@sentry/esbuild-plugin';
import esbuild from 'esbuild';
import path from 'path';

const sentryPlugin = sentryEsbuildPlugin({
  org: 'foo',
  project: 'bar',
  authToken: 'token'
});

esbuild.build({
  bundle: true,
  entryPoints: [path.resolve(__dirname, '../src/index.ts')],
  outdir: path.resolve(__dirname, '../dist'),
  inject: [path.resolve(__dirname, './inject.ts')],
  plugins: [sentryPlugin],
  minify: false,
  sourcemap: true
});

build-config/inject.js

export const process = {cwd: () => '', env: {}};
export const global = globalThis;

src/index.ts

const FOO = process.env.FOO ? 'foo' : 'bar';
console.log(FOO);

Expected Result

Before esbuild 0.19 the output injection piece would look something like this:

...

  // build-config/inject.ts?sentryProxyModule=true
  var process, global;
  var init_inject = __esm({
    "build-config/inject.ts?sentryProxyModule=true"() {
      process = { cwd: () => "", env: {} };
      global = globalThis;
    }
  });

  // src/index.ts
  var require_src = __commonJS({
    "src/index.ts"() {
      init_inject();
      var FOO = process.env.FOO ? "foo" : "bar";
      console.log(FOO);
    }
  });

...

Actual Result

Instead, now it outputs something like this:

...

  // sentry-debug-id-stub:_sentry-debug-id-injection-stub?sentry-module-id=xxx
  var init_sentry_debug_id_injection_stub = __esm({
    "sentry-debug-id-stub:_sentry-debug-id-injection-stub?sentry-module-id=xxx"() {
      init_inject2();
      !function() {
        try {
          var e = "undefined" != typeof window ? window : "undefined" != typeof global ? global : "undefined" != typeof self ? self : {}, n = new Error().stack;
          n && (e._sentryDebugIds = e._sentryDebugIds || {}, e._sentryDebugIds[n] = "xxx", e._sentryDebugIdIdentifier = "sentry-dbid-xxx");
        } catch (e2) {
        }
      }();
    }
  });

  // build-config/inject.ts
  var init_inject = __esm({
    "build-config/inject.ts"() {
      init_inject2();
    }
  });

  // build-config/inject.ts?sentryProxyModule=true
  var init_inject2 = __esm({
    "build-config/inject.ts?sentryProxyModule=true"() {
      init_sentry_debug_id_injection_stub();
      init_inject();
      init_inject();
    }
  });
...

There seems to be some weird circular relationship between the inject functions, and the addition of init_sentry_debug_id_injection_stub which previously wasn't there. The piece causing the actual issue is the lack of var process, global; which seems to be gone altogether

[Lms24]

Hi @ilijapuaca thanks for investigating! We need to take a look at this. Backlogging for now.
If you feel "Hacktoberfesty", feel free to open a PR if you find a way to fix this :) (no pressure though)

[lforst]

@ilijapuaca Hey, so I attempted to reproduce your problem. I couldn't encounter what you were describing so I added an integration test to our test suite that verifies this. Can you check whether this actually tests what you are describing?: #416

[lforst]

@ilijapuaca Nevermind I see the issue now. I was confused because in the tests process.env was obviously available because we run them with node. This issue should be fixed with #417.

[ilijapuaca]

Thanks for a quick patch! I was under the impression that it happened due to debug ID being injected into the files that the user is injecting themselves, but out of curiosity, any idea why it started happening with the new release of esbuild?

I also saw that a new release went out, impressive turnaround :)

[lforst]

any idea why it started happening with the new release of esbuild?

@ilijapuaca Honestly no idea. Nothing in the esbuild release notes strikes me as breaking for our case. Did you upgrade from 18.x or earlier?

[ilijapuaca]

0.18.6 -> 0.19.0 was the initial upgrade I did where it broke, I then gave 0.18.20 a try and things still worked, so it seems to be 0.19.0 and I couldn't find anything suspicious in the release notes either

[lforst]

I'm gonna say it's a blip and not gonna worry about it anymore 😄 Thanks for reporting this and following up!