logging.incomingRequests added version
The logging.incomingRequests option was added in v15.2.0.
Next.js · API reference · all subjects
config
577 notes in this subject, read out of this brain and free to use. This is page 4 of 10.
logging.serverFunctions option
Server Function invocations are logged by default during development, showing the function name, arguments, and duration. This can be disabled by setting logging.serverFunctions to false in next.config.js.
browserToTerminal stable release
The browserToTerminal option was added as stable in v16.2.0, having been previously experimental as experimental.browserDebugInfoInTerminal which was introduced in v15.4.0.
logging.fetches App Router only
The logging.fetches configuration for App Router moved to stable in v14.0.0, with the hmrRefreshes option added in v15.0.0.
browser console logs source location info
When logging.browserToTerminal is enabled, browser logs include source location information by default, showing the file path and line number. The output format is [browser] <message> (<filepath>:<line>:<column>). For example: [browser] Hello World (app/page.tsx:8:17)
logging.browserToTerminal option values
The logging.browserToTerminal option accepts the following values: 'warn' (forward only warnings and errors, the default), 'error' (forward only errors), true (forward all console output including log, info, warn, error), and false (disable browser log forwarding). This option forwards browser console logs to the terminal during development.
logging.incomingRequests option
The logging.incomingRequests option controls which incoming requests are logged during development. It can be set to false to disable all incoming request logging, or configured with an ignore array containing regex patterns for requests to exclude. This option only affects development mode and does not impact production builds.
logging.serverFunctions output format
When logging.serverFunctions is enabled, Server Function calls are displayed in the terminal with the format: POST / followed by the function name with arguments and duration. For example: POST / └─ ƒ myAction(arg1, arg2) in 5ms app/actions.ts
logging.fetches.hmrRefreshes option
The logging.fetches.hmrRefreshes option enables logging of fetch requests that are restored from the Server Components HMR cache. By default these requests are not logged, but setting this to true will log them during development.
logging.fetches.fullUrl option
The logging.fetches.fullUrl option enables logging the full URL for fetch requests in the console during development. It is a boolean option set within the logging.fetches object in next.config.js.
logging config option overview
The logging configuration in next.config.js controls logging behavior in the terminal during Next.js development mode. It can be set to false to disable all development logging, or configured with specific options for fetches, server functions, incoming requests, and browser console logs.
mdxRs config option
The mdxRs option is an experimental config setting used with @next/mdx that enables the new Rust compiler to compile MDX files in the App Router. It is set as a boolean property within the experimental object in next.config.js.
mdxRs experimental status
The mdxRs feature is experimental and is intended for use with @next/mdx for compiling MDX files using a new Rust-based compiler.
mdxRs example configuration
To enable the Rust MDX compiler, set mdxRs to true in the experimental section of next.config.js and configure @next/mdx as shown: const withMDX = require('@next/mdx')(); const nextConfig = { pageExtensions: ['ts', 'tsx', 'mdx'], experimental: { mdxRs: true, }, }; module.exports = withMDX(nextConfig)
onDemandEntries maxInactiveAge
The maxInactiveAge property (in milliseconds) specifies the period where the server will keep pages in the buffer. Default value is 25000 (25 seconds).
onDemandEntries config option
The onDemandEntries option in next.config.js controls how the development server disposes or keeps pages in memory. It accepts two properties: maxInactiveAge and pagesBufferLength.
onDemandEntries pagesBufferLength
The pagesBufferLength property specifies the number of pages that should be kept simultaneously in memory without being disposed. Default value is 2.
onDemandEntries example configuration
Configure onDemandEntries in next.config.js like this: module.exports = { onDemandEntries: { maxInactiveAge: 25 * 1000, pagesBufferLength: 2, }, }
optimizePackageImports performance benefit
Packages that export hundreds or thousands of modules can cause performance issues in development and production. Using optimizePackageImports mitigates these issues by only loading the modules that are actually imported.
Default optimized packages in Next.js
The following packages are optimized by default in Next.js without requiring configuration: lucide-react, date-fns, lodash-es, ramda, antd, react-bootstrap, ahooks, @ant-design/icons, @headlessui/react, @headlessui-float/react, @heroicons/react/20/solid, @heroicons/react/24/solid, @heroicons/react/24/outline, @visx/visx, @tremor/react, rxjs, @mui/material, @mui/icons-material, recharts, react-use, @material-ui/core, @material-ui/icons, @tabler/icons-react, mui-core, react-icons/*, effect, @effect/*.
optimizePackageImports syntax
The optimizePackageImports configuration is set in next.config.js under the experimental object. Example: module.exports = { experimental: { optimizePackageImports: ['package-name'] } }
optimizePackageImports config option
The optimizePackageImports experimental config option in next.config.js allows you to optimize packages that export hundreds or thousands of modules. By adding a package to experimental.optimizePackageImports as an array, Next.js will only load the modules you are actually using, while allowing you to write import statements with named exports for convenience.
outputFileTracingRoot config option
In monorepo setups, set outputFileTracingRoot in next.config.js to specify the root directory for file tracing. By default, the project directory where next build is run is used as the tracing root. Use path.join(__dirname, '../../') to include files from parent directories outside the immediate project folder.
outputFileTracingIncludes for native/runtime assets
Common patterns for including native or runtime assets in traces: ```js module.exports = { outputFileTracingIncludes: { '/*': ['node_modules/sharp/**/*', 'node_modules/aws-crt/dist/bin/**/*'], }, } ```
Copying public and static folders to standalone
To serve public and .next/static from the standalone server, manually copy them after next build using: cp -r public .next/standalone/ && cp -r .next/static .next/standalone/.next/. The server.js file will then automatically serve these folders.
Combining outputFileTracingRoot with includes in monorepo
In monorepos, combine outputFileTracingRoot with outputFileTracingIncludes to include files outside the app folder. Example: ```js module.exports = { outputFileTracingRoot: path.join(__dirname, '../../'), outputFileTracingIncludes: { '/route1': ['../shared/assets/**/*'], }, } ```
outputFileTracingIncludes with src directory
When using a src/ directory, outputFileTracingIncludes keys still match the route path (/api/hello, /products/[id], etc.) while values can reference paths under src/ since they are resolved relative to the project root. Example: outputFileTracingIncludes: { '/products/*': ['src/lib/payments/**/*'], '/*': ['src/config/runtime/**/*.json'] }
outputFileTracingIncludes and outputFileTracingExcludes example
Example configuration: ```js module.exports = { outputFileTracingExcludes: { '/api/hello': ['./un-necessary-folder/**/*'], }, outputFileTracingIncludes: { '/api/another': ['./necessary-folder/**/*'], '/api/login/\\[\\[\\.\\.\\.slug\\]\\]': [ './node_modules/aws-crt/dist/bin/**/*', ], }, } ```
outputFileTracingExcludes and outputFileTracingIncludes config options
These options in next.config.js handle cases where Next.js fails to include required files or incorrectly includes unused files. Both accept an object where keys are route globs (matched against route paths like /api/hello using picomatch) and values are glob patterns resolved from the project root. Keys match route paths and patterns can reference paths under src/. These options apply to server traces only; Edge Runtime routes and fully static pages are not affected.
How Output File Tracing works
Next.js uses @vercel/nft to statically analyze import, require, and fs usage to determine which files a page might load. The production server is also traced and output to .next/next-server.js.nft.json. The .nft.json files emitted to .next contain lists of traced files relative to the .nft.json file location.
Output File Tracing purpose
During next build, Next.js automatically traces each page and its dependencies to determine all files needed for production deployment. This drastically reduces deployment size compared to including all node_modules dependencies.
running standalone server.js with PORT and HOSTNAME
The minimal server.js in the standalone folder respects PORT and HOSTNAME environment variables. Start it with: node .next/standalone/server.js. For example, PORT=8080 HOSTNAME=0.0.0.0 node server.js starts the server on http://0.0.0.0:8080.
standalone folder minimal server.js
When output: 'standalone' is enabled, Next.js generates a minimal server.js file in .next/standalone that can be used instead of next start. This server does not copy the public or .next/static folders by default; these should be handled by a CDN or copied manually to standalone/public and standalone/.next/static after the build.
output config option: 'standalone' mode
Set output: 'standalone' in next.config.js to automatically create a .next/standalone folder that contains only the necessary files for production deployment, including select files in node_modules. This folder can be deployed without installing node_modules.
Global route key in outputFileTracingIncludes
Use the global key '/*' in outputFileTracingIncludes to target all routes. Example: outputFileTracingIncludes: { '/*': ['src/i18n/locales/**/*.json'] }
Output File Tracing best practices
Use forward slashes (/) in patterns for cross-platform compatibility. Keep patterns as narrow as possible to avoid oversized traces; avoid using **/* at the repo root. Patterns used in outputFileTracingExcludes and outputFileTracingIncludes apply only to server traces, not to Edge Runtime routes or fully static pages.
outputHashSalt config option
outputHashSalt is a configuration option that incorporates a configurable salt string into every content-addressed output filename, including chunks and assets. Changing this value forces all output hashes to change, which is useful for invalidating cached assets across deployments without modifying source files.
outputHashSalt version history
outputHashSalt was added in version 16.3.0.
outputHashSalt configuration in next.config.js
To configure the output hash salt, set the outputHashSalt property in next.config.js. Example: const nextConfig = { outputHashSalt: 'my-deployment-salt', }; module.exports = nextConfig;
outputHashSalt with Webpack and Turbopack
The outputHashSalt option works with both Webpack and Turbopack bundlers.
NEXT_HASH_SALT environment variable
The NEXT_HASH_SALT environment variable can be used for the same purpose as the outputHashSalt configuration option. When both outputHashSalt and NEXT_HASH_SALT are set, the values are concatenated (outputHashSalt + NEXT_HASH_SALT) to form the effective salt. This allows combining a per-project salt baked into the config with a per-deployment salt injected at build time via environment variable.
pageExtensions Pages Router example
Example next.config.js configuration for Pages Router: module.exports = { pageExtensions: ['mdx', 'md', 'jsx', 'js', 'tsx', 'ts'], };
pageExtensions affects all pages in Pages Router
When using the Pages Router, changing pageExtensions values affects all Next.js pages, including proxy.js, instrumentation.js, pages/_document.js, pages/_app.js, and pages/api/. If you reconfigure file extensions (for example, changing .ts to .page.ts), you must rename all these files accordingly.
pageExtensions example with MDX
To add markdown and MDX support to pages, configure pageExtensions in next.config.js with the withMDX plugin: const withMDX = require('@next/mdx')(); const nextConfig = { pageExtensions: ['js', 'jsx', 'ts', 'tsx', 'md', 'mdx'], }; module.exports = withMDX(nextConfig);
pageExtensions config option
pageExtensions is a Next.js configuration option in next.config.js that specifies which file extensions Next.js should recognize as page files. By default, Next.js accepts files with extensions: .tsx, .ts, .jsx, .js. This can be modified to include other extensions like .md or .mdx.
pageExtensions default value
The default pageExtensions value is an array containing: .tsx, .ts, .jsx, .js.
pageExtensions for colocating non-page files
To colocate test files or other non-page files in the pages directory without them being treated as pages, configure pageExtensions to require a specific pattern like .page. For example, set pageExtensions to ['page.tsx', 'page.ts', 'page.jsx', 'page.js'], then rename all pages to use this pattern (e.g., MyPage.tsx becomes MyPage.page.tsx). This must include all Next.js pages like _document.js, _app.js, proxy.js, instrumentation.js, and files in pages/api/.
poweredByHeader config option
Next.js adds the x-powered-by header by default. To disable it, set poweredByHeader to false in next.config.js.
poweredByHeader configuration example
module.exports = { poweredByHeader: false, }
prefetchInlining threshold tradeoffs
Lower prefetchInlining thresholds keep more per-segment deduplication. Higher thresholds inline more data and reduce request count further.
prefetchInlining maxSize option
The maxSize option for prefetchInlining controls the largest a single segment response can be to still be eligible for inlining. It is measured in bytes of the gzip-compressed segment response. The default value is 2048 bytes.
prefetchInlining only configuration is experimental
The inlining behavior is a permanent part of the App Router. Only the experimental.prefetchInlining configuration option itself is experimental, so its options may still change in future versions.
prefetchInlining maxBundleSize option
The maxBundleSize option for prefetchInlining controls the largest total size that can be inlined into one bundled prefetch response along a path. It is measured in bytes of the gzip-compressed segment response. The default value is 10240 bytes.
prefetchInlining disabling example
To disable prefetch inlining in next.config.ts, set experimental.prefetchInlining to false: const nextConfig: NextConfig = { experimental: { prefetchInlining: false } }; export default nextConfig;
prefetchInlining custom thresholds example
To override prefetchInlining thresholds in next.config.ts, pass an object with maxSize and maxBundleSize properties: const nextConfig: NextConfig = { experimental: { prefetchInlining: { maxSize: 2048, maxBundleSize: 10240 } } }; export default nextConfig;
prefetchInlining config option
The experimental.prefetchInlining option in next.config.ts or next.config.js controls how the App Router bundles small prefetch responses. It can be set to true (default, uses default thresholds), false (disables inlining, each segment is prefetched as its own request), or an object with maxSize and maxBundleSize properties to customize thresholds.
prefetchInlining default behavior
By default, the App Router bundles small segment responses into a single prefetch response instead of requesting each segment separately. This reduces the number of prefetch requests but duplicates some shared segment data across routes. The default is on for most applications.
prefetchInlining version history
experimental.prefetchInlining was added in version 16.2.0 and enabled by default starting in version 16.3.0.
productionBrowserSourceMaps config option
productionBrowserSourceMaps is a configuration flag in next.config.js that enables browser source map generation during the production build. It is a boolean option set to true or false. When enabled, source maps are output in the same directory as the JavaScript files, and Next.js will automatically serve these files when requested.
Source maps disabled by default in production
Source maps are enabled by default during development. During production builds, they are disabled by default to prevent leaking source code on the client, unless you specifically opt-in with the productionBrowserSourceMaps configuration flag set to true.