Next.js Blogتوسعه وب

Turbopack: What's New in Next.js 16.2

Turbopack in Next.js 16.2 brings faster builds, SRI support, postcss.config.ts, tree shaking of dynamic imports, Server Fast Refresh, inline loader configuration, and over 200 bug fixes.

Tim Neutkens ۴ دقیقه مطالعهمتن اصلی

Tim Neutkens,

Andrew Imm

Two releases after Turbopack became the default bundler for Next.js, we're focused on improving performance, fixing bugs, and increasing parity. Here are some of the latest features shipping as part of Next.js 16.2.

Looking forward towards our next release, we'll be focused on speeding up compiler performance and reducing memory usage.

We've reworked how server-side code is reloaded during development. The previous system cleared the

require.cache

for the changed module and all other modules in its import chain. This approach often reloaded more code than necessary, including unchanged

node_modules

.

The new system brings the same Fast Refresh approach used in the browser to your server code. Turbopack's knowledge of the module graph means only the module that actually changed is reloaded, leaving the rest intact. This makes server-side hot reloading significantly more efficient.

In real-world Next.js applications, we've seen 67-100% faster application refresh and 400-900% faster compile time inside Next.js. These results scale from the smallest "hello world" starter project to large sites like

vercel.com

.

Server refresh time on a sample Next.js site

375% faster

Before

40ms

19ms

59ms

After

2.7ms

9.7ms

12.4ms

Next.js (40ms → 2.7ms)

Application (19ms → 9.7ms)

Today we're enabling this feature for all developers, by default. Proxy and Route Handlers will use the existing system today, but support for those is arriving in a future release. Share your feedback or any issues with this new feature on GitHub.

Previously, Web Workers were bootstrapped through a

blob://

URL. This streamlined loading the worker, but it set an empty

location.origin

value. Web Worker code that tried to use

importScripts()

or

fetch()

(usually in third-party libraries) would have been unable to resolve the request without changes.

With the updated Worker bootstrap code, the

origin

correctly points to your domain name, and relative fetches succeed. This should unblock anyone who had trouble running WASM code inside a Worker in previous versions.

Turbopack now supports Subresource Integrity (SRI). SRI generates cryptographic hashes of your JavaScript files at build time, allowing browsers to verify that files haven't been modified.

Browsers provide a technology called Content Security Policy that allows sites to restrict the JavaScript that can run, eliminating entire classes of security issues. However, the typical

nonce

-based method for implementing this requires all pages to be dynamically rendered, impacting performance. Subresource Integrity is an alternative that computes a hash of each script ahead of time, and only allows the browser to execute scripts with approved hashes.

const nextConfig = {
  experimental: {
    sri: {
      algorithm: 'sha256',
    },
  },
};
 
module.exports = nextConfig;

Turbopack now tree shakes destructured dynamic imports the same way it does static imports. Unused exports are removed from the bundle:

const { cat } = await import('./lib');

This is now equivalent to a static import for tree shaking purposes — any exports from

./lib

that aren't used will be tree-shaken.

Turbopack now supports per-import loader configuration via import attributes. Instead of applying loaders globally through

turbopack.rules

, you can configure them on individual imports using the

with

clause:

import rawText from './data.txt' with {
  turbopackLoader: 'raw-loader',
  turbopackAs: '*.js',
};
import value from './data.js' with {
  turbopackLoader: 'string-replace-loader',
  turbopackLoaderOptions: '{"search":"PLACEHOLDER","replace":"replaced value"}',
};

This is useful when only a specific import needs special treatment, avoiding side effects on other imports of the same file type. The available attributes are

turbopackLoader

,

turbopackLoaderOptions

,

turbopackAs

, and

turbopackModuleType

.

You should still prefer configuring your loaders in

next.config.ts

when possible, since code using inline loaders is less portable. This option is more useful for code generated from plugins or loaders.

Lightning CSS is a fast, Rust-based CSS transformer used by Turbopack for CSS minification and prefixing. It also allows implementation of modern CSS features on older browsers, similar to what Babel or SWC do for JavaScript. Previously, the only way to toggle these settings was through a Browserslist configuration. Now with the experimental

lightningCssFeatures

option, you can force certain features to always or never transpile.

import type { NextConfig } from 'next';
 
const nextConfig: NextConfig = {
  experimental: {
    useLightningcss: true,
    lightningCssFeatures: {
      include: ['light-dark', 'oklab-colors'],
      exclude: ['nesting'],
    },
  },
};
 
export default nextConfig;

Turbopack can now suppress noisy or expected warnings from streaming logs with the

turbopack.ignoreIssue

config option. This is useful for suppressing warnings from third-party code, generated files, or optional dependencies, as well as hiding expected errors from the Next.js error overlay.

You can match logs generated from specific code paths, as well as filter for specific title/description strings or patterns.

import type { NextConfig } from 'next';
 
const nextConfig: NextConfig = {
  turbopack: {
    ignoreIssue: [
      { path: '**/vendor/**' },
      { path: 'app/**', title: 'Module not found' },
      { path: /generated\/.*\.ts/, description: /expected error/i },
    ],
  },
};
 
export default nextConfig;

Turbopack now supports

postcss.config.ts

in addition to the existing

.js

and

.cjs

variants.

We've continued to invest in improving Turbopack internals. Over 200 changes and bug fixes have improved stability and compatibility across a wide range of projects. Optimizations in data encoding, internal representation formats, and hashing algorithms have improved memory usage and build time. We've made error logs clearer and expanded diagnostics to help you better understand compiler errors. We've also used your GitHub Issues as a guide for which features were missing since the 16.1 release.

Share your feedback and help shape the future of Next.js:

#Performance#Browsers#JavaScript#CSS#Next.js#Turbopack

منتشرشده در

Next.js Blog

خواندن در منبع

ادامه مطالعه