-
Link to the code that reproduces this issuehttps://github.com/jmikrut/nextjs-68805 To Reproduce
Current vs. Expected behaviorTurbopack fails to compile, and the terminal blows up with errors such as the following: If you install dependencies with Yarn, or with Note that all dependencies which error are indeed installed as dependencies of installed packages. Webpack works, but Turbopack does not. Provide environment informationOperating System:
Platform: darwin
Arch: arm64
Version: Darwin Kernel Version 24.0.0: Wed Jul 31 21:51:10 PDT 2024; root:xnu-11215.0.199.501.2~1/RELEASE_ARM64_T6000
Available memory (MB): 32768
Available CPU cores: 10
Binaries:
Node: 20.11.1
npm: 10.2.4
Yarn: 1.16.0
pnpm: 8.15.7
Relevant Packages:
next: 15.0.0-canary.111 // Latest available version is detected (15.0.0-canary.111).
eslint-config-next: 15.0.0-canary.104
react: 19.0.0-rc-06d0b89e-20240801
react-dom: 19.0.0-rc-06d0b89e-20240801
typescript: 5.5.4
Next.js Config:
output: N/AWhich area(s) are affected? (Select all that apply)Turbopack Which stage(s) are affected? (Select all that apply)next dev (local) Additional contextThis appears to have broken in |
Beta Was this translation helpful? Give feedback.
Replies: 55 comments 7 replies
-
|
@jmikrut Not running into this error myself |
Beta Was this translation helpful? Give feedback.
-
|
Hey @samcx you need to load up the admin UI (the spot that uses the dependencies in question). I forgot to add that to the reproduction instructions - good catch. Updated! If you're still not able to repro, I also noticed that you're on |
Beta Was this translation helpful? Give feedback.
-
|
I don't get that error (I'm on pnpm 9.7.0) The |
Beta Was this translation helpful? Give feedback.
-
|
@jmikrut It seems error out because I don't have the correct keys. Where do I should I go create my keys (ideally, a |
Beta Was this translation helpful? Give feedback.
-
|
Ah apologies for that, let me update with a simpler repro that doesn't require keys. 1 sec |
Beta Was this translation helpful? Give feedback.
-
|
@samcx I updated with a proper repro that simplifies and does not require environment variables. Should just need to clone the newly linked repro above and run it with turbo to see it fail. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @samcx I created a very, very minimal reproduction of this issue here: https://github.com/AlessioGr/very-minimal-turbo-bug-repro It's a blank, fresh Next.js project that includes a small, local package in the The import { drizzle } from 'drizzle-orm/libsql';
import { createClient } from '@libsql/client';
export async function test(dbURL) {
const client = createClient({ url: dbURL });
const db = drizzle(client);
console.log('db', db);
}It has the following dependencies: Calling Within the Next.js app/page.tsx we're using that package like this: import { test } from 'mydep';
export default function Home() {
test('file:./test-sqlite.db')
return (
<p>
test
</p>
);
}Super simple! External package uses drizzle-orm and @libsql/client to connect to sqlite - that external package is then used within the page.tsx. When running When running I shouldn't have to install But Turbopack currently does not respect this. It would be a nightmare for package authors to force their users to install their packages' own dependencies |
Beta Was this translation helpful? Give feedback.
-
|
Hmm, it seems to not just be that package. I was able to confirm! I will be sharing this with the |
Beta Was this translation helpful? Give feedback.
-
|
Good news, it was already reported internally—we are taking a look! |
Beta Was this translation helpful? Give feedback.
-
|
Fantastic - thank you all! |
Beta Was this translation helpful? Give feedback.
-
|
Did something happen in canary 114? |
Beta Was this translation helpful? Give feedback.
-
|
@khuezy what version were you using before? |
Beta Was this translation helpful? Give feedback.
-
|
(Responding to #68805 (comment)) Due to various implementation detail intricacies in pnpm, that does indeed work because that external package is available even though it wasn't actually declared anywhere as a dependency to pnpm. To demonstrate how the old (Webpack) behavior could break your app, I modified your reproduction: https://github.com/mischnic/turbopack-externals-repro (commit 571437bb) to trigger a just-as severe or even worse failure mode where the external dependency version might change after building.
So now mydep has actually imported With growing project size, this becomes more likely because there are simply more dependencies and possibilities for hoisting to not do what you want. Turbopack fails and tells you what is going wrong: (And in the next canary, will also include the offending version numbers: #68871) This is why I think that the Turbopack error message is helpful to prevent these kind of (hard to diagnose) problems. To maybe explain some of the behavior you're seeing with older versions: Before canary 84, Turbopack didn't externalize dependencies inside node_modules (so if libsql should be external, that would only have worked in user code and not when importing libsql in some other package), now it behaves like Webpack. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @mischnic I see why a version mismatch is an issue and why it makes sense to throw an error there - we do something similar in our project for critical dependencies. However, I think this might be a separate issue than what we're experiencing here. I see how it makes sense in your modified repro since there are 2 conflicting versions of the dependency installed, but in my repro, there is only a single version of the drizzle-orm / libsql dependency installed. The external package declares it, and the consuming Next.js project does not. The underlying error is also different. Yours mentions
which totally makes sense. However, our error is
No dependency version mismatch |
Beta Was this translation helpful? Give feedback.
-
|
@samcx it may be a mismatch version the others have stated. I had an older version of https://github.com/vercel/next.js/releases/tag/v15.0.0-canary.113 |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
Hello, Any updates for this issue ? I've already this error... Thanks you
|
Beta Was this translation helpful? Give feedback.
-
|
Getting the same just trying to use pino from an internal common package in pnpm monorepo |
Beta Was this translation helpful? Give feedback.
-
|
I was getting the following warning when running turbo with sentry installed Then I installed This at least hid the warnings for me |
Beta Was this translation helpful? Give feedback.
-
|
Hey Next.js team - thank you for making these warnings instead of full-on errors. That is a good step. Everything works and is fully functional at this point but WOAH there are lots of warnings being logged. Looks like the warnings log on every request. Maybe you could consider adding a flag to silence these specific warnings in the Next.js config? That would be huge and with that I'd be all set on this issue. |
Beta Was this translation helpful? Give feedback.
-
|
@jmikrut Can you share a screenshot of these warnings? I would usually lean on fixing the warning instead of outright silencing it. Silencing a warning may lead to the warning never getting fixed. |
Beta Was this translation helpful? Give feedback.
-
|
I don't understand what is there for users to fix. Is this suggesting that I install this Example 2: As you can guess from the path, this dependency comes from the build folder of another package in a monorepo. But the main project only imports the auth package Finally, here is an example of my terminal log, just to give you a feel of how annoying this is in terms of DX: |
Beta Was this translation helpful? Give feedback.
-
|
@jmikrut The solution on the PNPM side for Sqlite adapter and turbopack is to publicly hoist legacy-peer-deps=true
public-hoist-pattern[]=*@libsql* |
Beta Was this translation helpful? Give feedback.
-
Apply the public-hoist-pattern settings in your root .npmrc (https://pnpm.io/npmrc#public-hoist-pattern). This worked for me, I'm following Julius' "Migrating a T3 app into a Turborepo" guide, and splitting out a drizzle libsql db from a nextjs app into it's own package. |
Beta Was this translation helpful? Give feedback.
-
|
I've found this issue too and initially thought that it was a hoisting issue. But it's apparently caused by mismatching version of the dependency that's being used by different workspace. A silly mistake So for example, I had a monorepo with this structure:
The symptom of mismatching version would have individual workspace with seemingly duplicate package in The solution is to change the While this may not be the replicated the original problem of the thread, hopefully this helps for those who are stuck. |
Beta Was this translation helpful? Give feedback.
-
|
@simoami Try this in Note that you need to install the dependencies again. |
Beta Was this translation helpful? Give feedback.
-
|
@r34son Thanks for the suggestion. I had them before but the warnings didn't go away. However, with the following extra steps it worked:
|
Beta Was this translation helpful? Give feedback.
-
|
Just adding these lines to my Note that you need to install the dependencies again. That was the trick for me. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks a lot@r34son, can you add the note from @geovanygameros to your message which is super helpful? |
Beta Was this translation helpful? Give feedback.
-
Unfortunately, this didn't work for me... even after reinstalling my deps I had to install |
Beta Was this translation helpful? Give feedback.
-
The .pnpmrc file works for development only, but for the build, I need to add the dependency and update next.config.js as you suggested, @simoami. Thanks a lot! |
Beta Was this translation helpful? Give feedback.
-
this worked for me |
Beta Was this translation helpful? Give feedback.
-
|
Even with the hoist workaround, it still does not work for me (without installing these packages in the project directly):
other related versions: pnpm 10.4.0 |
Beta Was this translation helpful? Give feedback.
-
|
same here tried all mentioned above its not working |
Beta Was this translation helpful? Give feedback.
-
|
Hi. facing the same issue with ⚠ ./node_modules/bullmq/dist/esm/classes
Package ioredis can't be external
The request ioredis/built/utils matches serverExternalPackages (or the default list).
The request could not be resolved by Node.js from the importing module. The way Node.js resolves modules is slightly different from the way Next.js resolves modules. Next.js was able to resolve it, while Node.js would not be able to.
Try to remove this package from serverExternalPackages. Or update the import side to use a compatible request that can be resolved by Node.js.I'm starting a let initialized = false;
export async function register() {
if (process.env.NEXT_RUNTIME === "nodejs" && !initialized) {
const { initializeWorkers } = await import("./workers");
await initializeWorkers();
initialized = true;
}
}I also have |
Beta Was this translation helpful? Give feedback.
-
|
yes, same for me. i was able to remove the other warning with the tricks mentioned, but not this one coming from bullmq |
Beta Was this translation helpful? Give feedback.
and others
@simoami Try this in
.npmrc:Note that you need to install the dependencies again.