Other Options

These are the remaining configuration options supported by webpack.

amd

object boolean: false

Set the value of require.amd or define.amd. Setting amd to false will disable webpack's AMD support.

webpack.config.js

export default {
  // ...
  amd: {
    jQuery: true,
  },
};

Certain popular modules written for AMD, most notably jQuery versions 1.7.0 to 1.9.1, will only register as an AMD module if the loader indicates it has taken special allowances for multiple versions being included on a page.

The allowances were the ability to restrict registrations to a specific version or to support different sandboxes with different defined modules.

This option allows you to set the key your module looks for to a truthy value. As it happens, the AMD support in webpack ignores the defined name anyways.

bail

boolean = false

Fail out on the first error instead of tolerating it. By default webpack will log these errors in red in the terminal, as well as the browser console when using HMR, but continue bundling. To enable it:

webpack.config.js

export default {
  // ...
  bail: true,
};

This will force webpack to exit its bundling process.

dependencies

[string]

A list of name defining all sibling configurations it depends on. Dependent configurations need to be compiled first.

In watch mode dependencies will invalidate the compiler when:

1. the dependency has changed
2. a dependency is currently compiling or invalid

Remember that current configuration will not compile until its dependencies are done.

webpack.config.js

export default [
  {
    name: "client",
    target: "web",
    // …
  },
  {
    name: "server",
    target: "node",
    dependencies: ["client"],
  },
];

ignoreWarnings

[RegExp, function (WebpackError, Compilation) => boolean, {module?: RegExp, file?: RegExp, message?: RegExp}]

Tells webpack to ignore specific warnings. This can be done with a RegExp, a custom function to select warnings based on the raw warning instance which is getting WebpackError and Compilation as arguments and returns a boolean, an object with the following properties:

• file : A RegExp to select the origin file for the warning.
• message : A RegExp to select the warning message.
• module : A RegExp to select the origin module for the warning.

ignoreWarnings must be an array of any or all of the above.

export default {
  // ...
  ignoreWarnings: [
    {
      module: /module2\.js\?[34]/, // A RegExp
    },
    {
      module: /[13]/,
      message: /homepage/,
    },
    /warning from compiler/,
    (warning) => true,
  ],
};

loader

object

Expose custom values into the loader context.

For example, you can define a new variable in the loader context:

webpack.config.js

export default {
  // ...
  loader: {
    answer: 42,
  },
};

Then use this.answer to get its value in the loader:

custom-loader.js

export default function (source) {
  // ...
  console.log(this.answer); // will log `42` here
  return source;
}

name

string

Name of the configuration. Used when loading multiple configurations.

This is especially useful when exporting an array of configurations. webpack uses name to identify each config in logs and stats output.

webpack.config.js

export default {
  // ...
  name: "admin-app",
};

For multi-configuration builds:

export default [
  {
    name: "client",
    target: "web",
    // ...
  },
  {
    name: "server",
    target: "node",
    // ...
  },
];

parallelism

number = 100

Limit the number of parallel processed modules. Can be used to fine tune performance or to get more reliable profiling results.

Lower values reduce concurrent work and memory pressure, but may increase total build time. Higher values can improve throughput on powerful machines.

webpack.config.js

export default {
  // ...
  parallelism: 50,
};

Use cases:

• Reduce parallelism when builds hit memory limits (for example in constrained CI runners).
• Increase it when you have enough CPU and memory and want to maximize build throughput.

profile

boolean

Capture a "profile" of the application, including statistics and hints, which can then be dissected using the Analyze tool. It will also log out a summary of module timings.

webpack.config.js

export default {
  // ...
  profile: true,
};

recordsInputPath

string

Specify the file from which to read the last set of records. This can be used to rename a records file. See the example below.

When this option is set, webpack reads previously generated records from this path and uses them as input for stable module/chunk id tracking.

webpack.config.js

import path from "node:path";
import { fileURLToPath } from "node:url";

const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);

export default {
  // ...
  recordsInputPath: path.join(__dirname, "records.json"),
  recordsOutputPath: path.join(__dirname, "records-next.json"),
};

recordsOutputPath

string

Specify where the records should be written. The following example shows how you might use this option in combination with recordsInputPath to rename a records file:

webpack.config.js

import path from "node:path";
import { fileURLToPath } from "node:url";

const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);

export default {
  // ...
  recordsInputPath: path.join(__dirname, "records.json"),
  recordsOutputPath: path.join(__dirname, "newRecords.json"),
};

recordsPath

string

Use this option to generate a JSON file containing webpack "records" – pieces of data used to store module identifiers across multiple builds. You can use this file to track how modules change between builds. To generate one, specify a location:

webpack.config.js

import path from "node:path";
import { fileURLToPath } from "node:url";

const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);

export default {
  // ...
  recordsPath: path.join(__dirname, "records.json"),
};

Records are particularly useful if you have a complex setup that leverages Code Splitting. The data can be used to ensure the split bundles are achieving the caching behavior you need.

snapshot

object

snapshot options decide how the file system snapshots are created and invalidated.

webpack.config.js

import path from "node:path";
import { fileURLToPath } from "node:url";

const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);

export default {
  // ...
  snapshot: {
    managedPaths: [path.resolve(__dirname, "../node_modules")],
    immutablePaths: [],
    unmanagedPaths: [],
    buildDependencies: {
      hash: true,
      timestamp: true,
    },
    module: {
      timestamp: true,
    },
    contextModule: {
      hash: true,
      timestamp: true,
    },
    resolve: {
      timestamp: true,
    },
    resolveBuildDependencies: {
      hash: true,
      timestamp: true,
    },
  },
};

buildDependencies

object = { hash boolean = true, timestamp boolean = true }

Snapshots for build dependencies when using the persistent cache.

• hash: Compare content hashes to determine invalidation (more expensive than timestamp, but changes less often).
• timestamp: Compare timestamps to determine invalidation.

Both hash and timestamp are optional.

• { hash: true }: Good for CI caching with a fresh checkout which doesn't keep timestamps and uses hashes.
• { timestamp: true }: Good for local development caching.
• { timestamp: true, hash: true }: Good for both cases mentioned above. Timestamps are compared first, which is cheap because webpack doesn't need to read files to compute their hashes. Content hashes will be compared only when timestamps are the same, which leads to a small performance hit for the initial build.

immutablePaths

(RegExp | string)[]

An array of paths that are managed by a package manager and contain a version or a hash in their paths so that all files are immutable.

webpack records nothing at all for files below these paths — no timestamp, no content hash — and never checks them again. Reserve it for directories whose path itself changes whenever the content changes, such as the zip cache of Yarn Plug'n'Play, where the package version is part of the path. Editing a file below an immutable path will not invalidate anything that was built from it.

A regular expression here is only tested against the path, so it doesn't need a capture group.

managedPaths

(RegExp | string)[]

An array of paths that are managed by a package manager and can be trusted to not be modified otherwise.

For files below these paths webpack does not snapshot the files themselves. It instead determines the package directory that contains the file and records name@version as read from that directory's package.json. Everything built from the package is invalidated when that string changes — which happens when the package manager installs a different version — and not when a file inside the package is edited in place. That is the difference from immutablePaths: a managed path is still re-checked on every build, just once per package instead of once per file.

"Otherwise" in the description above means exactly this: if you edit a file in node_modules by hand, or a tool patches one after install without changing the version, webpack keeps using the cached result. List such packages under unmanagedPaths (or narrow managedPaths, as shown below) so their files are snapshotted individually.

Make sure the directory that contains the packages is wrapped in the first capture group of your regular expression, so webpack can extract it — for example, here's a RegExp webpack internally uses to match the node_modules directory:

/^(.+?[\\/]node_modules[\\/])/

Note that the capture group includes the trailing slash. Without it, webpack would treat the node_modules directory itself as the managed item instead of the package directories inside it.

A common use case for managedPaths would be to exclude some folders from node_modules, e.g. you want webpack to know that files in the node_modules/@azure/msal-browser folder are expected to change, which can be done with a regular expression like the one below:

export default {
  snapshot: {
    managedPaths: [
      /^(.+?[\\/]node_modules[\\/](?!(@azure[\\/]msal-browser))(@.+?[\\/])?.+?)[\\/]/,
    ],
  },
};

unmanagedPaths

(RegExp | string)[]

An array of paths that are not managed by a package manager and the contents are subject to change.

It is checked before immutablePaths and managedPaths, so it is the way to carve a directory out of them — a linked package inside node_modules, for example. Files below an unmanaged path are snapshotted individually, according to snapshot.module and snapshot.resolve.

A regular expression here is only tested against the path, so it doesn't need a capture group.

module

object = { timestamp boolean = true }

Snapshots for building modules. In production mode the default is { timestamp: true, hash: true }.

• hash: Compare content hashes to determine invalidation (more expensive than timestamp, but changes less often).
• timestamp: Compare timestamps to determine invalidation.

contextModule

object = { timestamp boolean = true }

Snapshots for building context modules.

• hash: Compare content hashes to determine invalidation (more expensive than timestamp, but changes less often).
• timestamp: Compare timestamps to determine invalidation.

resolve

object = { timestamp boolean = true }

Snapshots for resolving of requests. In production mode the default is { timestamp: true, hash: true }.

• hash: Compare content hashes to determine invalidation (more expensive than timestamp, but changes less often).
• timestamp: Compare timestamps to determine invalidation.

resolveBuildDependencies

object = {hash boolean = true, timestamp boolean = true}

Snapshots for resolving of build dependencies when using the persistent cache.

• hash: Compare content hashes to determine invalidation (more expensive than timestamp, but changes less often).
• timestamp: Compare timestamps to determine invalidation.

validate

boolean

Whether webpack validates the configuration, and the options passed to loaders and plugins, against their schemas. Defaults to true, except in a production build with experiments.futureDefaults enabled, where it defaults to false.

webpack.config.js

export default {
  // ...
  validate: false,
};

Turning validation off skips that work on every build, so a typo in an option is no longer reported — keep it on while a configuration is still changing, and turn it off once a build is known good and the time it takes is worth saving.