import hook incompatible with `tsx`

[nwalters512]

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.0.0

Framework Version

No response

Link to Sentry event

No response

SDK Setup

Sentry.init({
  dsn: 'https://examplePublicKey@o0.ingest.sentry.io/0',
});

Steps to Reproduce

I've created a minimal reproduction here: https://github.com/nwalters512/sentry-v8-tsx-error-repro

1. Clone the repository
2. Install dependencies with yarn
3. Run yarn tsx src/index.ts
4. Observe that the process fails with the error TypeError [ERR_INVALID_URL_SCHEME]: The URL must be of scheme file

Several observations that are hopefully helpful to y'all:

• This only occurs when "allowJs": true is set in tsconfig.json. As Sentry isn't concerned with this, that made me think this problem might actually be in tsx. However...

• When adding instrumentation directly with the @opentelemetry/* packages, everything works fine. This is reproducible by making the following change to src/index.ts:

  -import './instrument-sentry.js';
  +import './instrument-opentelemetry.js';

  Given this, I'm strongly inclined to believe that this is an issue with the way in which Sentry is using OpenTelemetry.

• This only breaks for core Node modules like util, fs, etc. Importing other modules works fine. For instance, the following change to src/index.ts makes it work without erroring:

  -await import('util');
  +await import('zod');

• This only breaks for dynamic imports. For instance, the following change to src/index.ts makes it work without erroring:

  -await import('util');
  +import 'util';

Expected Result

I would expect the process to complete successfully and log util imported!.

Actual Result

The process errors out while importing util and does not print util imported!.

[timfish]

The full stack trace is:

TypeError [ERR_INVALID_URL_SCHEME]: The URL must be of scheme file
    at new NodeError (node:internal/errors:406:5)
    at fileURLToPath (node:internal/url:1393:11)
    at finalizeResolution (node:internal/modules/esm/resolve:234:42)
    at moduleResolve (node:internal/modules/esm/resolve:845:10)
    at defaultResolve (node:internal/modules/esm/resolve:1043:11)
    at nextResolve (node:internal/modules/esm/hooks:833:28)
    at y (file:///Users/tim/Documents/Repositories/sentry-v8-tsx-error-repro/node_modules/tsx/dist/esm/index.mjs?1715684968701:2:2079)
    at j (file:///Users/tim/Documents/Repositories/sentry-v8-tsx-error-repro/node_modules/tsx/dist/esm/index.mjs?1715684968701:2:3198)
    at nextResolve (node:internal/modules/esm/hooks:833:28)
    at resolve (/Users/tim/Documents/Repositories/sentry-v8-tsx-error-repro/node_modules/@opentelemetry/instrumentation/node_modules/import-in-the-middle/hook.js:238:23) {
  code: 'ERR_INVALID_URL_SCHEME'
}

And here is the bottom of the call stack.

Maybe the loader hook added by import-in-the-middle is somehow clashing with the loader hooks added by tsx?

[timfish]

Looking at the stack trace, although import-in-the-middle is at the bottom, further up we see frames from tsx:

    at y (file:///Users/tim/Documents/Repositories/sentry-v8-tsx-error-repro/node_modules/tsx/dist/esm/index.mjs?1715684968701:2:2079)
    at j (file:///Users/tim/Documents/Repositories/sentry-v8-tsx-error-repro/node_modules/tsx/dist/esm/index.mjs?1715684968701:2:3198)

I guess it's not handling the params the iitm adds to the url?

So I've opened an issue there:
privatenumber/tsx#554

[nwalters512]

@timfish thanks for investigating this; your small reproduction that used just import-in-the-middle was very helpful. I'm relatively confident that the issue here is in fact with import-in-the-middle and the fact that it appends query parameters to the URL it returns from its resolvers. That is, consider this line:

https://github.com/DataDog/import-in-the-middle/blob/00b01fff1f5b69dd25e307593ec54d1d8abb4844/hook.js#L259

Changing that to just url: url.url makes your reproduction complete without error (though I have no idea what effect that has on import-in-the-middle actually working).

Specifically, it looks like the issue is that this URL with ?iitm=true ends up as the parentURL in a subsequent resolution, which you can see by adding console.log(specifier, context) immediately after https://github.com/privatenumber/tsx/blob/e2afc60bbcc299e09a5bf0e0c8909b6766b633a2/src/esm/hook/resolve.ts#L39:

file:///Users/nathan/git/tsx/node_modules/.pnpm/import-in-the-middle@1.7.4/node_modules/import-in-the-middle/lib/register.ts {
  conditions: [ 'node', 'import', 'node-addons' ],
  importAttributes: {},
  parentURL: 'node:util?iitm=true'
}

[timfish]

Tracing the resolving of the otel hooking, it looks like ?iitm=true is used so that iitm knows that the resolving is actually coming from its hook rather than the original location.

Adding the query to the parent URL should be fine as this is still a valid URL.

For example, the following code runs fine under both node and tsx:

import { register } from "node:module";

register(
  new URL(
    `data:application/javascript;base64,${Buffer.from(
      `
    export async function resolve(specifier, context, nextResolve) {
      if (context.parentURL) {
        context.parentURL += "?some=query";
      }
      console.log("resolve", specifier, context);
      return nextResolve(specifier, context);
    }
`
    ).toString("base64")}`
  ),
  import.meta.url
);

await import("node:util");

and outputs:

resolve node:util {
  conditions: [ 'node', 'import', 'node-addons' ],
  importAssertions: {},
  parentURL: 'file:///Users/tim/Documents/repro/test.ts?some=query'
}

node:util?iitm=true is also a valid URL so I'm not fully convinced that's causing the issue yet!