[Next.js] Figure out a way to silence the `import/require-in-the-middle` warnings for Turbopack

[lforst]

Description

Seems like Turbopack is more strict in what it will do when there would be 2 different versions of a package it could bundle. Currently it will refuse to build (?). Maybe we can iron out the kinks here.

 ⚠ ./node_modules/.pnpm/@[email protected]_@[email protected]/node_modules/@opentelemetry/instrumentation/build/esm/platform/node
Package import-in-the-middle can't be external
The request import-in-the-middle matches serverExternalPackages (or the default list).
The request could not be resolved by Node.js from the project directory.
Packages that should be external need to be installed in the project directory, so they can be resolved from the output files.
Try to install it into the project directory by running npm install import-in-the-middle from the project directory.

[benjick]

Can these be ignored?

[timfish]

Which warnings are these and what do they look like? Do these warnings still exist now that in v9 we use import-in-the-middle in a mode where it doesn't attempt to instrument everything?

[benjick]

These are the ones I get:

 ○ Compiling /login ...
 ✓ Compiled /login in 1488ms
 ⚠ ./node_modules/.pnpm/@[email protected]_@[email protected]/node_modules/@opentelemetry/instrumentation/build/esm/platform/node
Package import-in-the-middle can't be external
The request import-in-the-middle matches serverExternalPackages (or the default list).
The request could not be resolved by Node.js from the project directory.
Packages that should be external need to be installed in the project directory, so they can be resolved from the output files.
Try to install it into the project directory by running npm install import-in-the-middle from the project directory.


 ⚠ ./node_modules/.pnpm/@[email protected]_@[email protected]/node_modules/@opentelemetry/instrumentation/build/esm/platform/node
Package import-in-the-middle can't be external
The request import-in-the-middle matches serverExternalPackages (or the default list).
The request could not be resolved by Node.js from the project directory.
Packages that should be external need to be installed in the project directory, so they can be resolved from the output files.
Try to install it into the project directory by running npm install import-in-the-middle from the project directory.


 ⚠ ./node_modules/.pnpm/@[email protected]/node_modules/@sentry/node/build/cjs/sdk
Package import-in-the-middle can't be external
The request import-in-the-middle matches serverExternalPackages (or the default list).
The request could not be resolved by Node.js from the project directory.
Packages that should be external need to be installed in the project directory, so they can be resolved from the output files.
Try to install it into the project directory by running npm install import-in-the-middle from the project directory.


 ⚠ ./node_modules/.pnpm/@[email protected]_@[email protected]/node_modules/@opentelemetry/instrumentation/build/esm/platform/node
Package require-in-the-middle can't be external
The request require-in-the-middle matches serverExternalPackages (or the default list).
The request could not be resolved by Node.js from the project directory.
Packages that should be external need to be installed in the project directory, so they can be resolved from the output files.
Try to install it into the project directory by running npm install require-in-the-middle from the project directory.


 ⚠ ./node_modules/.pnpm/@[email protected]_@[email protected]/node_modules/@opentelemetry/instrumentation/build/esm/platform/node
Package require-in-the-middle can't be external
The request require-in-the-middle matches serverExternalPackages (or the default list).
The request could not be resolved by Node.js from the project directory.
Packages that should be external need to be installed in the project directory, so they can be resolved from the output files.
Try to install it into the project directory by running npm install require-in-the-middle from the project directory.

• [email protected]
• @sentry/[email protected]

[novelnet]

having same issues, two different versions of import-in-the-middle in @sentry/[email protected] causing the warnings ⚠ ./node_modules/@opentelemetry/instrumentation/build/esm/platform/node Package import-in-the-middle can't be external The request import-in-the-middle matches serverExternalPackages (or the default list). The package resolves to a different version when requested from the project directory (1.13.1) compared to the package requested from the importing module (1.11.2). Make sure to install the same version of the package in both locations.

[lforst]

@novelnet Yes, this is fixed by adding an override to your package manager to install one specific version. In the case of import-in-the-middle, the later version is usually the better choice.

[novelnet]

@lforst thank you, but means to keep track on all sentry updates which may change package versions. Would be nice to fix this on sentry's side

[lforst]

This is not 100% fixable on our side. We are not in control of other dependencies and what they install.

[MonstraG]

What should we do with the OP's case? (Not the version mismatch).

[lforst]

@MonstraG maybe what the error message suggests?

Try to install it into the project directory by running npm install import-in-the-middle from the project directory.

[benjick]

Is this unsolvable? It makes developing so annoying

[chargome]

Hey @benjick have you tried adding

public-hoist-pattern[]=*import-in-the-middle*
public-hoist-pattern[]=*require-in-the-middle*

to .npmrc?

or

pnpm add import-in-the-middle require-in-the-middle?

[Kief5555]

Using yarn, I get a different error more specific to the versioning of import-in-the-middle:

 ⚠ ./node_modules/@sentry/node/node_modules/@opentelemetry/instrumentation/build/esm/platform/node
Package import-in-the-middle can't be external
The request import-in-the-middle matches serverExternalPackages (or the default list).
The package resolves to a different version when requested from the project directory (1.11.2) compared to the package requested from the importing module (1.14.0).
Make sure to install the same version of the package in both locations.

[chargome]

The request import-in-the-middle matches serverExternalPackages (or the default list).

@Kief5555 could you try an override so you just get the 1.14.0 version?

[benjick]

@chargome ~~that worked for me, thanks a lot!~~

edit: it actually brought on other errors, like eslint not being found by packages in the workspace

[Kief5555]

The request import-in-the-middle matches serverExternalPackages (or the default list).

@Kief5555 could you try an override so you just get the 1.14.0 version?

It caused a lot more issues.

[chargome]

I assume you already tried just installing the package in your project?

[Kief5555]

I assume you already tried just installing the package in your project?

Yes. Met with a lot more errors

[Lms24]

If anyone can provide a minimal reproduction for this, we'd greatly appreciate it, thanks!

[MonstraG]

https://github.com/MonstraG/sentry-in-the-middle-bug

Steps:

1. clone
2. pnpm i
3. pnpm run dev
4. open localhost:3000
5. check terminal where you did pnpm run dev

[andreiborza]

Thanks @MonstraG as always :) we'll look into it.

[benjick]

How's it going? Debugging other issues in dev mode with this issue on-going is incredibly annoying. Will it ever get fixed?

[chargome]

Taking a look at this, thanks for the repro and the patience!

[chargome]

So Turbopack expects external packages to be resolvable from the project root, but pnpm's hoisting mechanics isolate dependencies in directories that Turbopack (maybe?) cannot traverse. This is an internal hoisting mechanics issue between two external tools (pnpm and Turbopack) which is why we can't fix this in the SDK.

Our documentation provides two working solutions (also in the case of the repro):

• Direct installation: pnpm add import-in-the-middle require-in-the-middle
• Opt-out of hoisting via .npmrc:

public-hoist-pattern[]=*import-in-the-middle*
public-hoist-pattern[]=*require-in-the-middle*

Both solutions resolve the warnings by making these packages available at the project root where Turbopack can find them.

Closing this as this is currently not actionable for us, but I will reach out to the Vercel team in case they can help out here!

[dnhyde]

Tried the solution from troubleshooting documentation but did not solve the problem.

What seems to work for me is:

1. delete pnpm-lock.yaml
2. update the next.config.ts with

const nextConfig: NextConfig = {
  transpilePackages: ["require-in-the-middle"],
  /* config options here */
};

using versions

"@sentry/nextjs": "^10.15.0",
"next": "15.3.3"

Also the approach reported in https://github.com/getsentry/sentry-javascript/issues/15209#issuecomment-2864028787 installing require-in-the-middle as devDependency worked.