import hook incompatible with tsx

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

Clone the repository
Install dependencies with yarn
Run yarn tsx src/index.ts
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!.

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?

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

@timfish

@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'
}

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!

@nwalters512

There are multiple outstanding PRs for import-in-the-middle (including the one from @nwalters512 🙏) that combined hopefully fix a wide range of issues.

Until they make it to a release, I've combined these into a patch that can be used with patch-package:
#12242 (comment)

If anyone can confirm that this fixes their issues that would be great!

Fix resolution of lib/register.js when using multiple loaders (#76)

Does the fact that this PR is closed means that now Sentry is compatible with tsx?

This issue is still open #12357, but this specific issue is fixed.

Just needs to be released - that will come out tomorrow most likely.

feat: Upgrade OTEL dependencies (#12388)

Hello, we've just released v8.8.0, which should hopefully resolve this ESM problem. Let us know if you updated and are still running into problems!

This issue might be fixed, but unfortunately tsx always adds it's loaders before others passed via --import so it's still not compatible:
#12357
privatenumber/tsx#571

import-in-the-middle parses the loaded code to find the imports and with the current order of the loaders, import-in-the-middle is passed TypeScript code which it cannot parse.

feat: Upgrade OTEL dependencies (#12388)

@timfish

@timfish I'm actually not using tsx or anything, only native nodejs type stripping: is there any solution for it?

node --experimental-strip-types --env-file=../../.env -r ./src/sentry.ts --watch ./src/index.ts

Sentry init file:

import * as Sentry from '@sentry/node';
import { nodeProfilingIntegration } from '@sentry/profiling-node';
import commonSentryConfig from 'common/commonSentryConfig.ts';
import ENV from '#api/env.ts';

// without these handlers, the process will exit on unhandled rejections swallowing errors and leaving us blind
process.on('unhandledRejection', console.error);
process.on('uncaughtException', console.error);

Sentry.init({
  ...commonSentryConfig,
  dsn: ENV.SENTRY_DSN,
  environment: ENV.APP_ENV,
  enabled: ENV.APP_ENV !== 'local',
  integrations: [nodeProfilingIntegration()],
  tracesSampleRate: 0.1, // send 10% of traces for performance monitoring
});

Sentry.setTag('application', 'api');

Results in:

TypeError: Missing internal module 'import-in-the-middle/hook.mjs'
    at requireBuiltin (node:internal/bootstrap/realm:429:19)
    at Hooks.register (node:internal/modules/esm/hooks:151:7)
    at ModuleLoader.register (node:internal/modules/esm/loader:567:33)
    at Function.register (node:internal/modules/esm/loader:900:35)
    at maybeInitializeEsmLoader (file:///Users/damians/Desktop/atlas/node_modules/.pnpm/@sentry+node@9.18.0/node_modules/@sentry/node/build/esm/sdk/initOtel.js:39:22)
    at _init (file:///Users/damians/Desktop/atlas/node_modules/.pnpm/@sentry+node@9.18.0/node_modules/@sentry/node/build/esm/sdk/index.js:104:5)
    at Module.init (file:///Users/damians/Desktop/atlas/node_modules/.pnpm/@sentry+node@9.18.0/node_modules/@sentry/node/build/esm/sdk/index.js:72:10)
    at /Users/damians/Desktop/atlas/services/api/src/sentry.ts:10:8
    at ModuleJobSync.runSync (node:internal/modules/esm/module_job:395:35)
    at ModuleLoader.importSyncForRequire (node:internal/modules/esm/loader:329:47) Promise {
  <rejected> TypeError: Missing internal module 'import-in-the-middle/hook.mjs'
      at requireBuiltin (node:internal/bootstrap/realm:429:19)
      at Hooks.register (node:internal/modules/esm/hooks:151:7)
      at ModuleLoader.register (node:internal/modules/esm/loader:567:33)
      at Function.register (node:internal/modules/esm/loader:900:35)
      at maybeInitializeEsmLoader (file:///Users/damians/Desktop/atlas/node_modules/.pnpm/@sentry+node@9.18.0/node_modules/@sentry/node/build/esm/sdk/initOtel.js:39:22)
      at _init (file:///Users/damians/Desktop/atlas/node_modules/.pnpm/@sentry+node@9.18.0/node_modules/@sentry/node/build/esm/sdk/index.js:104:5)
      at Module.init (file:///Users/damians/Desktop/atlas/node_modules/.pnpm/@sentry+node@9.18.0/node_modules/@sentry/node/build/esm/sdk/index.js:72:10)
      at /Users/damians/Desktop/atlas/services/api/src/sentry.ts:10:8
      at ModuleJobSync.runSync (node:internal/modules/esm/module_job:395:35)
      at ModuleLoader.importSyncForRequire (node:internal/modules/esm/loader:329:47)
}

A new version of import-in-the-middle was released today that should help with --experimental-strip-types.

If you upgrade import-in-the-middle or delete your lock file, you should get the new version.

Navigation Menu

Repository navigation

import hook incompatible with `tsx` #12011

Is there an existing issue for this?

How do you use Sentry?

Which SDK are you using?

SDK Version

Framework Version

Link to Sentry event

SDK Setup

Steps to Reproduce

Expected Result

Actual Result

51 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

import hook incompatible with tsx #12011

Description

Is there an existing issue for this?

How do you use Sentry?

Which SDK are you using?

SDK Version

Framework Version

Link to Sentry event

SDK Setup

Steps to Reproduce

Expected Result

Actual Result

Activity

timfish commented on May 14, 2024

timfish commented on May 14, 2024

nwalters512 commented on May 14, 2024

timfish commented on May 14, 2024

51 remaining items

timfish commented on May 24, 2024

lilouartz commented on Jun 6, 2024

AbhiPrasad commented on Jun 6, 2024

mydea commented on Jun 7, 2024

timfish commented on Jun 7, 2024

damianobarbati commented on May 13, 2025

timfish commented on May 13, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

import hook incompatible with `tsx` #12011