Node SDK generating Error: ENOENT: no such file or directory

[Yareaj]

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

Node v20.12.1

Link to Sentry event

https://ticket-tool-helper.sentry.io/issues/5357809318/?project=4507264120717312&query=is%3Aunresolved&referrer=issue-stream&stream_index=0

SDK Setup

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

init({
  dsn: process.env.SENTRY_DSN_URL,
  integrations: [
    nodeProfilingIntegration(),
  ],
  tracesSampleRate: 1.0,
  profilesSampleRate: 1.0
});

Steps to Reproduce

I'm using https://github.com/discordjs/discord.js and since I updated to Sentry v8, without changing any of my other dependencies, I'm facing the following error in a function that is simply trying to import a discord.js class.

[Error: ENOENT: no such file or directory, open 'C:\...\node_modules\@discordjs\builders\dist\@discordjs\formatters']

I think it's on sentry the root of the error given by the fact that when using @sentry/node@7.113.0 this error didn't happen. If I remove my sentry init, the program will work fine too

Expected Result

The program would not detect any error

Actual Result

A

[Error: ENOENT: no such file or directory, open 'C:\...\node_modules\@discordjs\builders\dist\@discordjs\formatters']

is captured as an error and stops the execution of the function that was doing an import

[FozzieHi]

I am also seeing this, but with a different library (although it is slightly related, as it depends on discord.js):

Error when loading '/app/dist/listeners/messageUpdate.js': [Error: ENOENT: no such file or directory, open '/app/node_modules/@sapphire/framework/dist/esm/@sapphire/result'] {
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: '/app/node_modules/@sapphire/framework/dist/esm/@sapphire/result'
}

This is the Dockerfile I am using: https://github.com/FozzieHi/FormulaOne/blob/87c9bdb9deb02ca6cc97f8ed3d1883f0e4be2716/Dockerfile

I've checked the path, node_modules/@sapphire/framework/dist/esm/@sapphire and it doesn't exist on v8 or the app running v7 either, so I think that this is v8 somehow changing the import path? I haven't dug into it further yet to see if it's caused by the sentry update itself, or the packages it brings with it. I also haven't checked if it's possibly related to source maps as that's the only other thing I can think of.

[FozzieHi]

I've tried disabling source maps but that hasn't fixed it.

I've taken a look at the directories again:

• Doesn't exist: node_modules/@sapphire/framework/dist/esm/@sapphire/result
• Does exist: node_modules/@sapphire/result/dist/esm

I'm not sure if it is somehow renaming the imports for these or not?

[chentsulin]

It might be caused by a bug in import-in-the-middle:

• no such file or directory DataDog/import-in-the-middle#59
• Imports from @react-email/components break with import-in-the-middle DataDog/import-in-the-middle#62
• Fails to resolve exports defined submodule when reexported by another package DataDog/import-in-the-middle#63

[rnenjoy]

Error: ENOENT: no such file or directory, open '/srv/http/dev-net23/backend/node_modules/.pnpm/puppeteer@22.9.0/node_modules/puppeteer/lib/esm/puppeteer/puppeteer-core/internal/puppeteer-core.js'
    at async open (node:internal/fs/promises:641:25)
    at async readFile (node:internal/fs/promises:1254:14)
    at async getSource (node:internal/modules/esm/load:42:14)
    at async defaultLoad (node:internal/modules/esm/load:127:34)
    at async nextLoad (node:internal/modules/esm/hooks:791:22)
    at async getExports (/srv/http/dev-net23/backend/node_modules/.pnpm/import-in-the-middle@1.7.4/node_modules/import-in-the-middle/lib/get-exports.js:63:21)
    at async processModule (/srv/http/dev-net23/backend/node_modules/.pnpm/import-in-the-middle@1.7.4/node_modules/import-in-the-middle/hook.js:134:23)
    at async processModule (/srv/http/dev-net23/backend/node_modules/.pnpm/import-in-the-middle@1.7.4/node_modules/import-in-the-middle/hook.js:160:20)
    at async getSource (/srv/http/dev-net23/backend/node_modules/.pnpm/import-in-the-middle@1.7.4/node_modules/import-in-the-middle/hook.js:269:60)
    at async load (/srv/http/dev-net23/backend/node_modules/.pnpm/import-in-the-middle@1.7.4/node_modules/import-in-the-middle/hook.js:335:26) {
    ```

Seems to be import-in-the-middle

[net-tech]

Was experiencing this too. We use a mono repo for our product and the issue also occurs in those.

Very annoying that this was not caught before the v8 release to be honest. It caused a 1h 30min downtime on a service for us in a Docker environment and took some investigation to figure out.

[mydea]

Was experiencing this too. We use a mono repo for our product and the issue also occurs in those.

Very annoying that this was not caught before the v8 release to be honest. It caused a 1h 30min downtime on a service for us in a Docker environment and took some investigation to figure out.

Hey, sorry about that. We have done extensive testing and added a bunch of test applications testing various environments, but sadly with the breadth of the JS ecosystem it is impossible to test all possible scenarios. :(

This is almost certainly a problem in import-in-the-middle, we're tracking upstream progress and will eventually try to contribute improvements there as well, if necessary. Sorry about the inconvenience!

[bbrzoska]

We're experiencing the same issue at Zendesk. Dynamic ESM imports stop working when Sentry 8 is installed. Have to keep using Sentry 7 for now.

[timfish]

It's worth noting that you can disable the ESM module hooks by setting _sentryEsmLoaderHookRegistered before calling Sentry.init

globalThis._sentryEsmLoaderHookRegistered = true;

Sentry.init({

You will lose OpenTelemetry auto-instrumentation but you'll still be able to use the rest of the SDK so this might help some upgrade in the meantime.

[timfish]

There are outstanding PRs for import-in-the-middle that hopefully fix a wide range of issues.

There is a patch available here that can be used with patch-package that should fix all outstanding issues.

[danilofuchs]

There are now 3 outstanding PRs for import-in-the-middle that 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: import-in-the-middle+1.7.4.patch

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

This patch is failing for me:

node:internal/process/esm_loader:34
      internalBinding('errors').triggerUncaughtException(
                                ^
TypeError [Error]: parentResolve is not a function
    at processModule (/home/danilo/salvy/salvy-api/node_modules/import-in-the-middle/hook.js:182:30)
    at async getSource (/home/danilo/salvy/salvy-api/node_modules/import-in-the-middle/hook.js:308:60)
    at async load (/home/danilo/salvy/salvy-api/node_modules/import-in-the-middle/hook.js:375:26)
    at async nextLoad (node:internal/modules/esm/hooks:866:22)
    at async Hooks.load (node:internal/modules/esm/hooks:449:20)
    at async handleMessage (node:internal/modules/esm/worker:196:18)

Maybe I configured something wrong? I have overriden import-in-the-middle to 1.7.4

[timfish]

@danilofuchs can you give more details of your setup so I can try and reproduce this?

EDIT

No worries, I've reproduced it using Node v22.2.0

[timfish]

Sorry, I found a merge bug in that patch. Could you try it again?

[nishant-compro]

We are also experiencing a similar issue in our Nuxt 3 monorepo. Disabling the ESM module hooks works for now.
[request error] [unhandled] [500] The requested module 'vue' does not provide an export named 'computed'

[timfish]

Hi @nishant-compro,

Did you try the patch? If the patch doesn't work, this could be a different issue.

[danilofuchs]

Sorry, I found a merge bug in that patch. Could you try it again?

The patch fixes the ENOENT: no such file or directory bug!
I had a different issue now related to openai package, also related to ESM (globalThis._sentryEsmLoaderHookRegistered = true; solves it)

[mydea]

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!

[arty-name]

The previous error is gone, however now I see __vite_ssr_import_2__.captureException is not a function.

console.log(captureException) prints undefined.

I’ve tried importing it in all ways:

import { captureException } from '@sentry/astro';
import * as Sentry from '@sentry/astro';
(await import('@sentry/astro')).captureException;

[mydea]

The previous error is gone, however now I see __vite_ssr_import_2__.captureException is not a function.

console.log(captureException) prints undefined.

I’ve tried importing it in all ways:

import { captureException } from '@sentry/astro';
import * as Sentry from '@sentry/astro';
(await import('@sentry/astro')).captureException;

Do you mind opening a new issue for this? This will help us to track this properly and ensure we can resolve this as soon as we can! 🙏

[arty-name]

Sure, I’ve created #12410

[rnenjoy]

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!

Just upgraded! My error with pupeteer are gone, and so are the instrumention error of Express. Great work!!

[Yareaj]

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!

Can confirm the issue was fixed, thanks!