Unexpected token errors coming from import-in-the-middle

[SerenModz21]

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

Framework Version

Node v20.14.0

Link to Sentry event

No response

SDK Setup

Sentry.init({
    dsn: envParseString("SENTRY_DSN"),
    integrations: [
        Sentry.nativeNodeFetchIntegration(),
        Sentry.consoleIntegration(),
        Sentry.onUncaughtExceptionIntegration(),
        Sentry.onUnhandledRejectionIntegration(),
        Sentry.functionToStringIntegration(),
        Sentry.modulesIntegration(),
        Sentry.linkedErrorsIntegration(),
        Sentry.httpIntegration(),
    ],
    tracesSampleRate: 1.0,
    environment: nodeEnvironment,
    release: `${name}@${version}`,
});

Steps to Reproduce

I simply had migrated from v7 to v8.

I was using 8.7.0 with globalThis._sentryEsmLoaderHookRegistered = true; until the "no such file or directory" got issue, which was the case with 8.8.0. Since installing the update, i commented out that line of code to check if everything had been fixed but i get spammed with the mentioned unexpected token errors.

Just like the "no such file or directory" error, i'm just gonna have to keep using globalThis._sentryEsmLoaderHookRegistered = true; or just fallback to v7 for the time being.

There is #12357 which is quite similar, the difference being that I do not use TSX but the standard TypeScript compiler. Where my startup is simly tsc && node --enable-source-maps .. In addition, my project involves discord.js, @sapphire/framework, and other sapphire plugins/utilities (eg. decorators)

Expected Result

Errors should not appear.

Actual Result

SyntaxError [Error]: Unexpected token (3:40)
    at pp$4.raise (PATH_REDACTED\node_modules\acorn\dist\acorn.js:3573:15)
    at pp$9.unexpected (PATH_REDACTED\node_modules\acorn\dist\acorn.js:772:10)
    at pp$9.semicolon (PATH_REDACTED\node_modules\acorn\dist\acorn.js:749:68)
    at Parser.parseImport (PATH_REDACTED\node_modules\acorn-import-attributes\lib\index.js:242:12)
    at pp$8.parseStatement (PATH_REDACTED\node_modules\acorn\dist\acorn.js:948:51)
    at pp$8.parseTopLevel (PATH_REDACTED\node_modules\acorn\dist\acorn.js:829:23)
    at Parser.parse (PATH_REDACTED\node_modules\acorn\dist\acorn.js:601:17)
    at Function.parse (PATH_REDACTED\node_modules\acorn\dist\acorn.js:651:37)
    at getEsmExports (PATH_REDACTED\node_modules\@opentelemetry\instrumentation\node_modules\import-in-the-middle\lib\get-esm-exports.js:37:23)     
    at getExports (PATH_REDACTED\node_modules\@opentelemetry\instrumentation\node_modules\import-in-the-middle\lib\get-exports.js:73:12) {    
  pos: 166,
  loc: { line: 3, column: 40 },
  raisedAt: 170
}

[Lms24]

Hi @SerenModz21 thanks for writing in and sorry for the troubles! I'm not yet sure how or why this error is thrown, especially because just transpiling with TSC shouldn't have an impact here. To debug this further:

• Just to confirm: Your're transpiling your code to ESM ("import" syntax), correct?
• which installation method of the Node SDK are you using?
  • related, are you passing the --import when you're starting your application as documented in the ESM-specific guides?

Let's first check if the SDK is set up correctly and go from there.

[SerenModz21]

I do indeed transpile to ESM. As for installation, that would be the late initialization method. Unfortunately however, I made the mistake of not trying with --import @sentry/node/preload; therefore, I will give such a try and provide an update on any further news. I am just a little confused how auto-instrumentation would make a difference in this situation.

[Lms24]

The --import @sentry/node/preload option ensures that import-in-the-middle and OpenTelemetry instrumentation is added early enough. I'm not sure if it makes a difference with your issue but IITM has been known for interfering with import syntax. Let's see if it changes something!

[timfish]

It could be the --enable-source-maps option which I have a suspicion could be implemented via loader hooks or at least hits the resolution hook.

I guess import-in-the-middle should be passing non-js files straight through to the next loader. Maybe if there are any exceptions iitm should console.error them but fall back to the next loader rather than fail at this point. It would make it less of a blocker when it fails on things like this.