Turbopack build feedback #77721
Replies: 89 comments 114 replies
-
|
when creating a standalone build and starting with just |
Beta Was this translation helpful? Give feedback.
-
|
This is no longer the case when using the latest canary release (that is going out as 15.3 soon). |
Beta Was this translation helpful? Give feedback.
-
|
why does with running however, running |
Beta Was this translation helpful? Give feedback.
-
|
Are you asking about the larger bundle size or the |
Beta Was this translation helpful? Give feedback.
-
thanks that explains it. |
Beta Was this translation helpful? Give feedback.
-
|
btw will turbopack have a replacement for webpack's bundle-analyzer? |
Beta Was this translation helpful? Give feedback.
-
|
@stefanprobst, we need a more polished long-term solution, but for now you can run See #81318 for details. |
Beta Was this translation helpful? Give feedback.
-
|
turbopack build does not correctly resolve fonts from next/font - #77861 |
Beta Was this translation helpful? Give feedback.
-
|
Did some digging into this and it seems to only happen with |
Beta Was this translation helpful? Give feedback.
-
|
next build --turbo with nextjs 15.3.0 generates chunks with invalid filenames on Windows. |
Beta Was this translation helpful? Give feedback.
-
|
I still get this warning in nextjs 16.0.0 but the build seems to succeed? |
Beta Was this translation helpful? Give feedback.
-
|
Any updates here? I get this warning in version |
Beta Was this translation helpful? Give feedback.
-
|
I am also getting the exact same error with version |
Beta Was this translation helpful? Give feedback.
-
|
Same error in 16.0.3. Is there a workaround for this? |
Beta Was this translation helpful? Give feedback.
-
I used the following in {
"scripts": {
"dev": "next dev --webpack",
"build": "next build --webpack",
"start": "next start"
}
} |
Beta Was this translation helpful? Give feedback.
-
import jackson from "@/server/services/jackson";
import { redirect } from "next/navigation";
export async function POST(req: Request) {
const { oauthController } = await jackson();
const formData = await req.formData();
const { redirect_url } = await oauthController.samlResponse({
RelayState: formData.get("RelayState") as string,
SAMLResponse: formData.get("SAMLResponse") as string,
});
redirect(redirect_url as string);
}import { clientEnv } from "@/env/client";
import { createUrl } from "@/lib/utils";
import jackson, {
type IConnectionAPIController,
type IDirectorySyncController,
type IOAuthController,
type ISPSSOConfig,
type JacksonOption,
type OIDCAuthzResponsePayload,
} from "@boxyhq/saml-jackson";
import config from "../db/config";
export type { OIDCAuthzResponsePayload };
interface Global {
apiController?: IConnectionAPIController;
oauthController?: IOAuthController;
directorySync?: IDirectorySyncController;
spConfig?: ISPSSOConfig;
}
const g: Global = global as unknown as Global;
const externalUrl = createUrl.subdomain("admin-cms").path();
const opts: JacksonOption = {
externalUrl: externalUrl,
samlAudience: clientEnv.NEXT_PUBLIC_APP_NAME,
samlPath: "/api/sso/acs",
oidcPath: "/api/sso/callback",
db: {
engine: "sql",
type: "mysql",
url: config.primary,
},
openid: {},
noAnalytics: true,
};
let apiController: IConnectionAPIController;
let oauthController: IOAuthController;
let directorySync: IDirectorySyncController;
let spConfig: ISPSSOConfig;
export default async function init() {
if (
!g.apiController ||
!g.oauthController ||
!g.directorySync ||
!g.spConfig
) {
const ret = await jackson(opts);
apiController = ret.apiController;
oauthController = ret.oauthController;
directorySync = ret.directorySyncController;
spConfig = ret.spConfig;
g.apiController = apiController;
g.oauthController = oauthController;
g.directorySync = directorySync;
g.spConfig = spConfig;
} else {
apiController = g.apiController;
oauthController = g.oauthController;
directorySync = g.directorySync;
spConfig = g.spConfig;
}
return {
apiController,
oauthController,
directorySync,
spConfig,
};
} |
Beta Was this translation helpful? Give feedback.
-
|
I'm having the same issue. Next 15.3.1 |
Beta Was this translation helpful? Give feedback.
-
|
Any update on this? I'm also having the same issue on Next 15.3.2. |
Beta Was this translation helpful? Give feedback.
-
|
I tested in the Next.js 15.4.0-canary.63 version, and it's now working properly. next build --turbopack builds in 36 seconds. 
next build uncached builds in 1 minute 23 seconds. 
|
Beta Was this translation helpful? Give feedback.
-
|
We are from LobeHub Team and building LobeChat with nextjs. I have tested the building with turbopack now and It's amazing fast! 
And Here is a compare of webpack and turbopack:
You can see turbopack reduce 60% building time! But there still an issue with integate with serwist: serwist/serwist#54 . Can wait to move to turbopack after this integration! |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Turbo build production fails with Prisma (tried on both 6.5.0 and 6.6.0 using the prisma-client-js generator): prisma schema folder structure prisma loaded in the frontend like this builds all ok without the turbo flag, and next dev --turbo also works fine |
Beta Was this translation helpful? Give feedback.
-
|
can you confirm that downgrading to 15.4.0-canary.35 breaks it again ? Be interested to know which commit fixes it ! |
Beta Was this translation helpful? Give feedback.
-
|
My build was completed successfully on 15.4.0-canary.35. |
Beta Was this translation helpful? Give feedback.
-
|
you know what my next comment will be haha |
Beta Was this translation helpful? Give feedback.
-
|
looks possibly like it was this commit in canary-28 this hopefully fixes it |
Beta Was this translation helpful? Give feedback.
-
|
I've checked, it's fixed in canary-28. |
Beta Was this translation helpful? Give feedback.
-
Build Performance Comparison
|
Beta Was this translation helpful? Give feedback.
-
|
خیلیییی سریعه 🔥🔥 |
Beta Was this translation helpful? Give feedback.
-
|
I with my small project don't see any performance benefits. Are we only supposed to see the benefits in bigger projects? I have even tried running the build command multiple times to see if i would get better results without any luck. I ran each of these with a clean build first. Hardware: running without > next build
▲ Next.js 15.3.0
- Experiments (use with caution):
✓ useCache
Creating an optimized production build ...
✓ Compiled successfully in 1000ms
✓ Linting and checking validity of types
✓ Collecting page data
✓ Generating static pages (6/6)
✓ Collecting build traces
✓ Finalizing page optimization
Route (app) Size First Load JS
┌ ƒ / 572 B 372 kB
├ ƒ /_not-found 990 B 105 kB
└ ƒ /login 572 B 372 kB
+ First Load JS shared by all 104 kB
├ chunks/1684-3cc8d39bf08bda7e.js 46.4 kB
├ chunks/4bd1b696-79901f1c062801da.js 53.2 kB
└ other shared chunks (total) 4.83 kB
ƒ Middleware 33.3 kB
ƒ (Dynamic) server-rendered on demand
npm run build 15.84s user 2.25s system 183% cpu 9.886 totalhyperfine benchmark running with > next build --turbopack
⚠ The config property `experimental.turbo` is deprecated. Move this setting to `config.turbopack` as Turbopack is now stable.
▲ Next.js 15.3.0 (Turbopack)
- Experiments (use with caution):
· turbo
✓ useCache
Creating an optimized production build ...
✓ Compiled successfully in 2.9s
✓ Linting and checking validity of types
✓ Collecting page data
✓ Generating static pages (6/6)
✓ Collecting build traces
✓ Finalizing page optimization
Route (app) Size First Load JS
┌ ƒ / 0 B 420 kB
├ ƒ /_not-found 0 B 420 kB
└ ƒ /login 0 B 420 kB
+ First Load JS shared by all 422 kB
├ chunks/1fa3394cc56fb597.js 77.1 kB
├ chunks/780cf8f2a2a5b7ec.js 13.1 kB
├ chunks/7e8ef395dd44ad63.js 270 kB
├ chunks/e694e57256351634.js 18.9 kB
└ other shared chunks (total) 42.9 kB
ƒ Middleware 50.5 kB
ƒ (Dynamic) server-rendered on demand
⚠ Support for Turbopack builds is experimental. We don't recommend deploying mission-critical applications to production.
- Turbopack currently always builds production sourcemaps for the browser. This will include project sourcecode if deployed to production.
- It is expected that your bundle size might be different from `next build` with webpack. This will be improved as we work towards stability.
- This build is without disk caching; subsequent builds will become faster when disk caching becomes available.
- When comparing output to webpack builds, make sure to first clear the Next.js cache by deleting the `.next` directory.
Provide feedback for Turbopack builds at https://github.com/vercel/next.js/discussions/77721
npm run build 22.58s user 3.21s system 237% cpu 10.879 totalhyperfine benchmark |
Beta Was this translation helpful? Give feedback.
-
|
Did you delete |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I actually did delete the .next folder between runs. That's what I ment by "I ran each of these with a clean build first.". I had the same thoughts as you to begin with and ended up running the benchmarks more than 3 times :) |
Beta Was this translation helpful? Give feedback.
-
|
Yeah fair, given this app is super small not expecting much wins, it compiles with webpack in <1s already. Could you share the project so I can compare and check why it takes longer with Turbopack. If you have e.g. Tailwind that could be the reason because we have to boot a separate Node.js process for it. |
Beta Was this translation helpful? Give feedback.
-
|
Probably some unhandled cases in 
After investigating the reason, it is because dynamic imports in a route handler that referenced client components |
Beta Was this translation helpful? Give feedback.
-
|
Sounds like the same as #77036 |
Beta Was this translation helpful? Give feedback.
-
|
It is a vast improvement from webpack. In Webpack it takes 10 mins to compile and with |
Beta Was this translation helpful? Give feedback.
-
|
Using Turbo with Reproduction: https://github.com/remcohaszing/turbo-markdown-error |
Beta Was this translation helpful? Give feedback.
-
|
Can we turn off Source maps manually? |
Beta Was this translation helpful? Give feedback.
-
|
We ran into two problems which directly crash the build (15.3.1-canary.8) Turbopack crashes with SWC plugins when using absolute paths in swcPlugins configuration #78156 SWC plugin context in Turbopack includes only basename instead of full path #78181 |
Beta Was this translation helpful? Give feedback.
-
|
Nextjs 16.0.1 breaks builds on Windows. This i a regression because in 16.0.0 this was treated as a warning. |
Beta Was this translation helpful? Give feedback.
-
|
My issue is related to @philipbushnell-valtech 's issue mentioned above I've been facing below mentioned error during The issue is not coming in Linux machines, but it is only giving this import related error in windows machine only I tried using Unfortunately I don't have a reproduction but its not working with Below i've mentioned the versions I'm using in my project. "dependencies": {
"next": "^16.0.1",
"react": "^19.2.0",
"react-dom": "^19.2.0",
"sass": "1.77.6",
"bootstrap": "^5.3.8",
}My main scss file @import 'bootstrap/scss/functions';
@import 'bootstrap/scss/variables';
@import 'bootstrap/scss/bootstrap';The issue is not related to bootstrap because its working fine with Below error is as-is copied from the terminal. |
Beta Was this translation helpful? Give feedback.
-
|
I've got the same issue with turbopack on Windows to have issues with resolving imports of bootstrap. --webpack flag solves issue on windows, while on linux it works on both |
Beta Was this translation helpful? Give feedback.
-
|
I've made an issue for it here |
Beta Was this translation helpful? Give feedback.
-
|
This is related to Nextjs 16 and 15. Feeback for turbopack in dev mode. Please let me know if anyone needs specific details. The This is a screenshot from the problematic code. |
Beta Was this translation helpful? Give feedback.
-
|
As the conversation and reports keep going in this discussion, sharing a new issue with repro for visibility: #85370 |
Beta Was this translation helpful? Give feedback.
-
|
Removing some dynamic imports works! Turbopack is much faster and is working great now. Thanks! 🙂 |
Beta Was this translation helpful? Give feedback.
-
|
Turbopack build works fine, runtime doesn't. Previously working w/ webpack in v15. Version: Very likely same issue from #77721 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
The actual issue seems to be related to jsdom here jsdom/jsdom#3977 (comment) I pinned the version and the runtime worked while using 16.0.1 |
Beta Was this translation helpful? Give feedback.
-
|
Upgrading to Next.js 16 and tried new default Turbopack, but it doesn't handle Sass CSS modules correctly:
Having to revert to |
Beta Was this translation helpful? Give feedback.
-
|
Turbopack emits chunks in a different order than Webpack, which can cause hydration to occur much later. That can result in user input being lost: #85782 I ran into this when I switched to Turbopack and a Cypress integration test started failing because the first few characters entered in the form would get lost. Weird issue! Easy to replicate, too. |
Beta Was this translation helpful? Give feedback.
-
|
ORM entity discovery using ReflectMetadataProvider with Turbopack build in production breaks MikroORM's functionality, Webpack works fine.
|
Beta Was this translation helpful? Give feedback.
-
|
Do I need to do something special to get Turbopack to output source maps with inline sources? I set |
Beta Was this translation helpful? Give feedback.
-
|
Going from next 14 to next 16. Getting warnings with In my next config (output standalone, not sure if that's relevant):
Warnings I get: I have two different top level packages which depend on different versions of this transitive dependency. This happens with other transitive dependencies as well. For example, For and strapi There are other issues such as a hydration warning with shadcn's navigation-menu component's Trigger sub-component which I don't get with webpack (seems to originate in radix) and the following: (This one seems similar to #77721 (comment) and #77721 (reply in thread)). The build does succeed and when I run locally, things seem to be fine, but would rather wait for these to go away before deploying a turbopack build. |
Beta Was this translation helpful? Give feedback.
-
|
I have serverSourceMaps: true in my next.config.js. When I build with Webpack, the server source files are correctly placed in .next/standalone for debugging. However, when I build with Turbopack (next build --turbo), these files are missing. Is there an additional configuration step required for Turbopack to handle this? How can I include server source maps in the .next/standalone folder when building a Next.js app with Turbopack? Edit: server source-maps are generated in .next folder but they are not copied in standalone folder |
Beta Was this translation helpful? Give feedback.
-
|
I’m using Next.js 16 with a maplibre-gl library that loads a basemap style from an external URL: Why does Turbopack fail to load an external style JSON URL while Webpack works? |
Beta Was this translation helpful? Give feedback.
-
|
On 16.0.3 turbopack runs into a problem with the copilot kit library: Running with |
Beta Was this translation helpful? Give feedback.
-
|
I ran into the same issue, you can circumvent this issue with the fix discussed here: Adding this to your next.config.js const nextConfig: NextConfig = {
serverExternalPackages: ['pino', 'pino-pretty', 'thread-stream'],
};And making sure that |
Beta Was this translation helpful? Give feedback.
-
|
It does, but since I am not using pino directly, it's a bit of a let-down having to do this. In my case, i can wrap @copilotkit-runtime, which I use directly, which is what I went for. Still, I wonder if there will be feature parity with webpack for scenarios such as this. Pino is just one example among many. |
Beta Was this translation helpful? Give feedback.
-
|
seconded that having to do a bunch of package sleuthing and installing stuff you are only using transitively is not a great developer experience |
Beta Was this translation helpful? Give feedback.
-
|
Using Bun as package manager. Next.js 15/16 works with Turbopack but generates loads of similar logs (probably related to Sentry) that disappear if I switch back to Webpack. Similar to #76247 but I'm using Bun not pnpm. |
Beta Was this translation helpful? Give feedback.
-
|
I've gotten similar logs with pnpm too |
Beta Was this translation helpful? Give feedback.
-
|
Installing manually (and the correct version) is a workaround to quiet the logs at least. |
Beta Was this translation helpful? Give feedback.
-
Turbopack Build Issue: Deep Relative Path Resolution FailsEnvironment
The ProblemTurbopack fails to resolve deep relative paths during We're using deep relative paths in an Nx monorepo to import generated files from nested directories: // Example import from a nested directory structure
import { gql } from '../../../../__generated__/unified/gql';Error: The error shows Turbopack is trying to resolve the relative path but failing. The path depth varies from 2-6 levels of What We Tried
Questions
Workaround: Using |
Beta Was this translation helpful? Give feedback.
and others
Uh oh!
There was an error while loading. Please reload this page.
-
Thread for posting feedback about
next build --turbopack.Beta Was this translation helpful? Give feedback.
All reactions