Next.js Discord

Discord Forum

next build --turbopack fails with TypeError: The "path" argument must be of type string

Unanswered
Maine Coon posted this in #help-forum
Open in Discord
Maine CoonOP
I'm trying to build a Next.js project using the experimental Turbopack feature by running next build --turbopack. The build process fails during the page data collection step with a TypeError, specifically stating: "The 'path' argument must be of type string. Received type number (92961)". The error is triggered when processing the route /api/admin/toggle-recruitment.

There haven't been any recent changes to that API route or its dependencies. The only change made was switching the build command in package.json to use Turbopack instead of the default Webpack builder. The relevant script now looks like this:

"scripts": {
  "build": "next build --turbopack"
}


Here’s a snippet of the error output for clarity:

TypeError: The "path" argument must be of type string. Received type number (92961)
    at 92961 (.next/server/chunks/_e42d0611._.js:6:5748)
    at instantiateModule (.next/server/chunks/[turbopack]_runtime.js:594:23)
    ...
[Error: Failed to collect page data for /api/admin/toggle-recruitment] {
  type: 'Error'
}


I've tried clearing the .next directory, double-checked for any accidental non-string paths, and confirmed that everything builds correctly using next build without the --turbopack flag. The project is running Next.js version 15.3.1 inside GitHub Codespaces.

This appears to be a Turbopack-specific issue and might be related to how it handles API routes. I’d appreciate any advice or confirmation from others who may have faced something similar. Thanks!

2 Replies

Maine CoonOP
Quick update on this issue: I dug deeper into the stack trace and noticed that the error at 92961 (.next/server/chunks/_e42d0611._.js:6:5748) seems to originate from Prisma Client's engine initialization and configuration system.

After inspecting the bundled code, it looks like Turbopack might be misinterpreting or incorrectly bundling a part of Prisma's internal logic, specifically something related to its dynamic path resolution. This could explain why a number (92961) is unexpectedly passed as a path argument, leading to the TypeError.

Just to clarify, this issue doesn't happen when using the default Webpack builder — Prisma initializes and runs as expected there. So this might be a compatibility issue between Turbopack and Prisma Client, possibly around how the engine loads or resolves its config during build.

If anyone else has managed to get Prisma working with Turbopack, I'd really appreciate hearing how you configured it or if any custom patches were needed. Otherwise, I may consider temporarily reverting to Webpack until this stabilizes.

Let me know if you want a minimal repro.
Maine CoonOP
Another update after digging into the compiled .next/server/chunks/_e42d0611._.js file:

The root cause seems to be coming from how Turbopack is handling or transforming the path module when resolving Prisma's engine paths. In the original source, there are multiple calls like:

M.default.join(__dirname, "../query-engine-darwin")


However, M is assigned via:

M = k(__turbopack_context__.r(578579))


This means Turbopack is injecting a module reference using __turbopack_context__.r(578579), and somehow k() ends up returning a number instead of the actual path module, causing the following error when .join() is called:

TypeError: The "path" argument must be of type string. Received type number (92961)


This suggests a few potential culprits:

* Turbopack is incorrectly resolving or optimizing the path module used by Prisma.
* k() (possibly a dynamic import wrapper from Prisma’s bundling logic) isn’t working correctly in the Turbopack context.
* Turbopack might be rewriting __dirname or file paths in an unexpected way during SSR bundle generation.

This seems to break Prisma’s logic that determines which query engine binary to use based on platform (e.g., query-engine-darwin, etc.).

Everything still works fine with the regular Webpack-based next build, so it’s almost certainly a Turbopack-specific issue.

If anyone’s run into similar problems with Prisma Client and Turbopack, or knows how to tell Turbopack to handle Node core modules (like path) more explicitly, I’d love some pointers.