Discuss compiler used by nextjs in details.
Next.js uses a Rust-based compiler architecture built on SWC, now featuring Turbopack as the default bundler since version 16, delivering significantly faster builds and Fast Refresh compared to the legacy Webpack/Babel setup.
Next.js has undergone a significant evolution in its compiler architecture, transitioning from JavaScript-based tools (Babel and Terser) to a Rust-powered stack. The foundation of this new architecture is SWC (Speedy Web Compiler) . Since version 12, Next.js has used SWC to replace Babel for transpilation and Terser for minification . This shift was the first major step toward faster build times, with Next.js reporting up to 17x faster compilation than the previous Babel setup.
1. SWC: The Foundation
SWC (Speedy Web Compiler) is an extensible Rust-based platform used for compilation, minification, and bundling . It is designed to be a low-level, embeddable engine that higher-level tools like Next.js can call to perform code transformations. SWC's performance advantages come from being written in Rust (compiled to native code) and its ability to aggressively parallelize work across multiple CPU cores. Benchmarks show SWC can be 20x faster than Babel on a single thread and up to 70x faster on four cores . Next.js uses SWC for core tasks including: transpiling JavaScript and TypeScript, handling JSX/TSX compilation, and minifying production bundles (7x faster than Terser) .
2. Turbopack: The Default Bundler (Next.js 16+)
Building on SWC, Next.js introduced Turbopack, a Rust-based incremental bundler designed specifically for the framework . Starting with Next.js 16, Turbopack became the default bundler for both development and production builds . Unlike Webpack, Turbopack uses a unified graph for all environments (client, server), bundles only what the dev server actually requests (lazy bundling), and caches results down to the function level for incremental computation .
Next.js 16 also provides stable built-in support for the React Compiler, which automatically memoizes components to reduce unnecessary re-renders without manual useMemo or useCallback . The compiler is not enabled by default, as it can increase build times. You can enable it in your Next.js configuration. Note that enabling this option will increase compile times in development and during builds, as the React Compiler relies on Babel .
4. Supported Features and Configuration
- 1
JavaScript & TypeScript (using SWC)
- 2
ECMAScript (ESNext) features
- 3
CommonJS and ESM modules
- 4
JSX / TSX compilation
- 5
Fast Refresh for instant feedback
- 6
React Server Components (RSC)
- 7
Global CSS and CSS Modules (via Lightning CSS)
- 8
CSS Nesting and @import
- 9
PostCSS (processes config files in Node.js worker pool)
- 10
Sass / SCSS support
- 1
styled-components: Built-in support via compiler.styledComponents config
- 2
Emotion: Built-in support via compiler.emotion config
- 3
Remove Console: compiler.removeConsole to strip console.* calls in production
- 4
Remove React Properties: compiler.reactRemoveProperties to strip test attributes
- 5
Relay: compiler.relay for GraphQL compilation
- 6
Jest integration: next/jest automatically configures SWC transforms
- 1
Webpack plugins are not supported; you must find Turbopack-compatible alternatives or continue using Webpack with the --webpack flag
- 2
Custom Sass functions (sassOptions.functions) are not supported because Turbopack's Rust architecture cannot execute JavaScript functions
- 3
Less is not yet supported by default (planned via plugins)
- 4
Some legacy CSS Modules features are not supported (e.g., :local/:global as standalone pseudo-classes, :import/:export ICSS rules)
- 5
Yarn PnP is not planned for Turbopack support
- 6
AMP support is not planned for Turbopack
- 1
Starting in Next.js 16, Turbopack automatically uses Babel if it detects a configuration file
- 2
Unlike Webpack, SWC is always used for Next.js's internal transforms even when Babel is present
- 3
Files in node_modules are excluded from Babel processing unless manually configured with babel-loader
If your application depends on features not yet supported by Turbopack (such as specific Webpack plugins or custom Sass functions), you can continue using Webpack by adding the --webpack flag to your dev and build scripts . This is also necessary for platforms without native Turbopack bindings, where Next.js falls back to WebAssembly (WASM) bindings that support core SWC features but not Turbopack .
Scenario Questions
- 1
How would you fix a Next.js app that’s slow to start in development mode because of long compilation times?
- 2
What happens if you import a Node.js-only module in a client component, and how does the compiler handle it?
- 1
Our Next.js app started failing to build after upgrading from v13 to v14 — the error mentions SWC transforms failing on a third-party library. How would you diagnose and resolve this?
- 2
We added a custom Babel plugin for legacy code, but now our build times doubled. What’s likely happening under the hood, and how would you fix it?
- 1
How would you design a build pipeline in Next.js that balances fast developer iteration with minimal production bundle size when using many dynamic imports and external APIs?
- 2
You’re seeing inconsistent hydration errors in production only — how would you trace whether this is a compiler issue, code splitting bug, or runtime mismatch?
- 1
We’re migrating a large legacy React app to Next.js and need to preserve custom Webpack configs while adopting SWC — how would you architect the transition to avoid build regressions across 50+ teams?
- 2
How would you evaluate whether to fully commit to SWC over Webpack for a global-scale Next.js app with complex asset pipelines, and what long-term maintenance risks would you plan for?
Follow-up Questions
- ❓How would you debug a build that works locally but fails in production?
- ❓What happens if you add a custom Webpack config alongside SWC?
- ❓Why might you see different behavior between dev and build modes?