Datagrid and Charting for Enterprise Applications
webpack
Proud to partner with webpack

Webpack 5.105 (2026-02-03)

Webpack 5.105 brings several improvements, both in code generation and bug fixes.

Two Low-Severity CVEs Fixed in Webpack

Two new low-severity CVEs in Webpack have been fixed and published. By default, you are safe; these issues only affect users of the experimental experiments.buildHttp option.

Affected CVEs:

CVE-2025-68157

CVE-2025-68458

Even though these are low-severity CVEs, it’s still a good idea to update if you use the affected versions.

For more information on reporting security vulnerabilities, see the Webpack Security Policy .

tsconfig.json Alias Resolution Without Requiring plugins

Module resolution can be configured to read compilerOptions.baseUrl and compilerOptions.paths from tsconfig.json and apply those aliases when resolving imports. As a result, it is no longer necessary to install and configure the external tsconfig-paths-webpack-plugin just to make TypeScript path aliases work during bundling.

In the webpack configuration, the resolve.tsconfig option is used to specify which tsconfig file should be used as the source (which is also useful in monorepos or setups with multiple tsconfig files):

// webpack.config.js
module.exports = {
  resolve: {
    tsconfig: "./tsconfig.json", // Can be `false` (disabled), `true` (use the default tsconfig.json), a path to a `tsconfig.json` file, or an object with configFile and references options.
  },
};

Example of aliases in tsconfig.json:

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"]
    }
  }
}

And then in the code:

import Button from "@/components/Button";

This way, @/components/Button can be resolved according to the rules defined in tsconfig.json, avoiding the need to duplicate aliases in resolve.alias and reducing discrepancies between what TypeScript understands and what the bundler resolves.

Automatic Module Resolution for Web Workers

When importing a package specifically to be used in a Web Worker in Webpack, module resolution can prioritize files like index.worker.js over index.js when using conditional exports defined in the exports field of package.json.

This means that if you define conditions such as "worker" in your package's exports, Webpack will automatically select the appropriate version, like index.worker.js, whenever the package is imported inside a worker context. There’s no need to modify the resolve.conditionNames option or make additional Webpack configuration changes; you just need to specify the conditions correctly in package.json.

For example, in package.json:

{
  "name": "foo",
  "exports": {
    ".": {
      "worker": "./index.worker.js",
      "default": "./index.js"
    }
  }
}

Now, when importing the foo package inside a Worker, Webpack will automatically choose the index.worker.js file according to the export conditions:

// This import is inside a Worker context, so Webpack uses index.worker.js
const worker = new Worker(new URL("foo", import.meta.url), {
  type: "module",
});

Support Import Specifier Guard

Support for import specifier guards has been added, an improvement that helps the bundler better understand a common pattern checking whether an export exists before using it. Previously, even if the code was correctly guarded by an if, the access could be interpreted as unconditional and result in warnings like “export … was not found”.

With this change, those checks are recognized as a signal that the access is conditional, and the analysis is adjusted accordingly. In practice, this makes it possible to write code that is more compatible across different versions of the same library, where an export may or may not exist, without unnecessary noise during compilation.

import * as React from "react";

if (React.useId) {
  // create guard for `React` => userId: ["", "useId"].
  React.useId; // React -> "useId" is in guard.
  React; //  React -> "" is in guard.
}

Support import.defer() for Context Module

Webpack now supports import.defer() even when the import is a context module (that is, when the import path is built dynamically and webpack needs to include a set of possible files). In practice, this makes it much easier to defer the loading of a module selected at runtime, even when that module comes from a dynamic expression pointing to a directory. This enables patterns like “choose between a.js or b.js and load it only when needed”, with webpack generating the appropriate context so that import.defer() works correctly.

const file = Math.random() > 0.5 ? "a.js" : "b.js";
import.defer("./dir/" + file);

Preserving Custom import.meta Properties

Webpack now preserves custom import.meta properties during bundling when output.module is enabled. Previously, Webpack would remove any unknown import.meta properties (such as import.meta.customProp), causing the loss of contextual or tool-specific information in the build.

With this change, any non-standard property you add to import.meta will remain intact in the generated code, allowing the use of custom meta-information or additional signals in modern applications.

if (!import.meta.UNKNOWN_PROPERTY) {
  // runtime assignment
  import.meta.UNKNOWN_PROPERTY = "HELLO";
}

If output.module is not enabled, Webpack will continue to remove unknown properties unless you explicitly indicate otherwise. To preserve them manually, you can configure module.parser.javascript.importMeta as 'preserve-unknown' in your webpack.config.js:

// webpack.config.js
module.exports = {
  module: {
    parser: {
      javascript: {
        importMeta: "preserve-unknown",
      },
    },
  },
};

This way, even without output.module: true, any custom import.meta property, such as import.meta.customProp, will be preserved in the build.

Better Control of Source Maps in devtool

Webpack now allows the devtool option to accept both a string and an array of objects for advanced configurations.

Each object in the array can include:

  • type: which can be "all", "css", or "javascript".
  • use: where you define the type of source map to generate.

This enables specifying different types of source maps for different resources in your project. For example:

// webpack.config.js
module.exports = {
  target: ["web", "node"],
  experiments: {
    css: true,
  },
  devtool: [
    {
      type: "javascript",
      use: "source-map",
    },
    {
      type: "css",
      use: "inline-source-map",
    },
  ],
};

In this example, standard source maps are applied to all modules, and inline source maps are used specifically for CSS files.

This new option is especially useful if you are using Webpack’s experimental CSS compilation feature, as it gives you greater control over the debugging process and improves integration with external tools.

It’s worth noting that the classic string syntax, like devtool: "source-map", remains fully valid and supported.

Cleaner ESM Output for Node.js and Modern Builds

This improvement in Webpack optimizes the handling and representation of Node.js native modules (such as fs, path, or crypto) during bundling, especially when using the output.module option in the configuration. When output.module: true is enabled, Webpack now generates imports of native modules using ES module syntax import ... from "module" instead of CommonJS require("module"), regardless of whether the code will run in a web or Node.js environment.

Other Improvements and Bug Fixes

  • Webpack-dev-server has released a new version to update dependencies that had reported transitive vulnerabilities, so updating is recommended. Additionally, the option to close the error overlay by pressing the ESC key has been added, and several bugs have been fixed. Check the release for more information.
  • Webpack-bundle-analyzer has received important improvements and fixes for the user experience. Visual issues with tooltips in dark mode have been resolved, and the analysis of bundles using IIFE has been made more robust, preventing errors. Additionally, support for Zstandard compression has been added, available only on Node.js 22.15 or higher. Check the changelog for more information
  • Mini-css-extract-plugin introduces new features and bug fixes. Among the main changes, the plugin now respects the output.cssFilename and output.cssChunkFilename options, allowing more precise control over the names of the generated CSS files. Additionally, a bug was fixed that prevented the generation of the contentHash for a chunk when the CSS module set had zero size, thus avoiding unnecessary hashes in those cases. Check the release for more information

Several bug fixes have been resolved since version 5.104. Check the changelog for more details

Thanks

A big thank you to all our contributors and sponsors who made Webpack 5.105 possible. Your support, whether through code contributions, documentation, or financial sponsorship, helps keep Webpack evolving and improving for everyone.

Edit this page·Print this page
« Previous
Roadmap 2026 (2026-02-04)

1 Contributor

bjohansebas