From 904b64c711a1e00e3aa448066660930c639cc59f Mon Sep 17 00:00:00 2001 From: Aviv Keller Date: Thu, 30 Jul 2026 17:37:19 -0700 Subject: [PATCH] update content --- CONTRIBUTING.md | 17 +- pages/about/index.md | 4 +- pages/about/license.md | 24 ++ .../posts/2020-10-10-webpack-5-release.md | 6 +- pages/blog/posts/2026-02-03-webpack-5-105.md | 18 +- pages/blog/posts/2026-02-04-roadmap-2026.md | 6 +- pages/blog/posts/2026-04-08-webpack-5-106.md | 2 +- pages/blog/posts/2026-05-19-webpack-5-107.md | 6 +- pages/blog/posts/2026-06-25-webpack-5-108.md | 375 ++++++++++++++++++ pages/blog/posts/2026-07-24-webpack-5-109.md | 309 +++++++++++++++ pages/docs/index.md | 10 +- pages/guides/cli/environments.md | 145 +++++++ pages/guides/cli/index.md | 169 ++++++++ pages/guides/cli/inspecting-builds.md | 150 +++++++ pages/guides/cli/running-builds.md | 189 +++++++++ pages/guides/cli/scaffolding.md | 77 ++++ pages/guides/contributing/writing-a-loader.md | 22 +- pages/guides/core-workflows/asset-modules.md | 15 + .../core-workflows/output-management.md | 2 +- pages/guides/core-workflows/public-path.md | 89 +++++ pages/guides/glossary.md | 82 ++++ .../guides/optimization/build-performance.md | 3 +- .../code-splitting/lazy-loading.md | 2 +- pages/guides/site.json | 26 +- pages/site.mjs | 1 + vercel.json | 15 +- 26 files changed, 1713 insertions(+), 51 deletions(-) create mode 100644 pages/about/license.md create mode 100644 pages/blog/posts/2026-06-25-webpack-5-108.md create mode 100644 pages/blog/posts/2026-07-24-webpack-5-109.md create mode 100644 pages/guides/cli/environments.md create mode 100644 pages/guides/cli/index.md create mode 100644 pages/guides/cli/inspecting-builds.md create mode 100644 pages/guides/cli/running-builds.md create mode 100644 pages/guides/cli/scaffolding.md create mode 100644 pages/guides/core-workflows/public-path.md create mode 100644 pages/guides/glossary.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index a6a49a5a..87a0b029 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -12,14 +12,15 @@ We hope this guide helps you find the right kind of contribution and get product The website assembles content from several sources, so the first step is confirming you are in the right place: -| You want to change… | Go to… | -| ---------------------------------------------------------- | ------------------------------------------------------------ | -| Guides, blog posts, or other hand-written pages (`pages/`) | **This repository** | -| The build tooling, API doc generation, or site theme | **This repository** | -| Generated API reference pages (`/docs/api/`) | [webpack/webpack](https://github.com/webpack/webpack) | -| Loader or plugin reference pages | The README of that loader or plugin's repository | -| The Markdown-to-HTML engine itself | [nodejs/doc-kit](https://github.com/nodejs/doc-kit) | -| webpack's actual behavior | [webpack/webpack](https://github.com/webpack/webpack/issues) | +| You want to change… | Go to… | +| ---------------------------------------------------------- | -------------------------------------------------------------------- | +| Guides, blog posts, or other hand-written pages (`pages/`) | **This repository** | +| The build tooling, API doc generation, or site theme | **This repository** | +| Generated API reference pages (`/docs/api/`) | [webpack/webpack](https://github.com/webpack/webpack) | +| Loader or plugin reference pages | The README of that loader or plugin's repository | +| The Markdown-to-HTML engine itself | [nodejs/doc-kit](https://github.com/nodejs/doc-kit) | +| webpack's actual behavior | [webpack/webpack](https://github.com/webpack/webpack/issues) | +| The CLI's actual behavior (flags, commands, scaffolding) | [webpack/webpack-cli](https://github.com/webpack/webpack-cli/issues) | When in doubt, [ask in the webpack Discord](https://discord.com/invite/webpack) and we will point you in the right direction. diff --git a/pages/about/index.md b/pages/about/index.md index bda63d0f..6ab35eff 100644 --- a/pages/about/index.md +++ b/pages/about/index.md @@ -59,7 +59,7 @@ output. webpack 5 introduced persistent caching, improved tree shaking, module federation, and the removal of automatic Node.js core polyfills. webpack being a bundler doesn't mean you give up a fast feedback loop during -development. The [`webpack-dev-server`](/docs/webpack-dev-server/) +development. The [`webpack-dev-server`](https://github.com/webpack/webpack-dev-server) provides live reloading and Hot Module Replacement, swapping updated modules into a running application without a full page refresh. Built on the same foundation, code splitting lets you break bundles into chunks that load on demand, keeping @@ -97,7 +97,7 @@ organization: webpack communicates through various official and community-supported channels. You can find details on how to get involved on the -[Get Involved](/contribute/) page, and you can support the +[Contributing guide](https://github.com/webpack/webpack/blob/main/CONTRIBUTING.md), and you can support the project through its [Open Collective](https://opencollective.com/webpack). ### Reporting Issues diff --git a/pages/about/license.md b/pages/about/license.md new file mode 100644 index 00000000..bf5c10bf --- /dev/null +++ b/pages/about/license.md @@ -0,0 +1,24 @@ +--- +title: License +authors: EugeneHlushko,pranshuchittora,avivkeller +--- + +# License + +Different parts of the webpack project are covered by different licenses. This page explains which applies to what. + +## webpack + +webpack is [MIT licensed](https://github.com/webpack/webpack/blob/main/LICENSE). The same applies to the loaders, plugins, and tooling published by the [webpack organization](https://github.com/webpack) unless a repository states otherwise. + +## webpack logo and icon + +The webpack logo and icon are **not** covered by the MIT license. They are published separately in the [webpack/media](https://github.com/webpack/media) repository under their own terms. See the [branding guidelines](/about/branding) before using them. + +## webpack documentation + +The content on [webpack.js.org](https://webpack.js.org) is available under the [Creative Commons Attribution 4.0 International](https://creativecommons.org/licenses/by/4.0/) license, which means attribution is required if you reuse it elsewhere. + +## webpack code samples + +The code samples embedded in this documentation are released under [CC0 1.0 Universal (Public Domain Dedication)](https://creativecommons.org/publicdomain/zero/1.0/). You are free to use them however you like, with no attribution required. diff --git a/pages/blog/posts/2020-10-10-webpack-5-release.md b/pages/blog/posts/2020-10-10-webpack-5-release.md index 983c286b..ce121f94 100644 --- a/pages/blog/posts/2020-10-10-webpack-5-release.md +++ b/pages/blog/posts/2020-10-10-webpack-5-release.md @@ -74,7 +74,7 @@ This release focus on the following: ## **Migration** Guide -[See here for a **migration** guide](/migrate/5) +[See here for a **migration** guide](/guides/migration/to-v5) ## Major Changes: Removals @@ -159,7 +159,7 @@ Webpack 5 adds a new feature called "Module Federation", which allows multiple w From runtime perspective modules from multiple builds will behave like a huge connected module graph. From developer perspective modules can be imported from specified remote builds and used with minimal restrictions. -For more details see [this separate guide](/concepts/module-federation). +For more details see [this separate guide](/guides/getting-started/concepts/module-federation). ## Major Changes: New Web Platform Features @@ -247,7 +247,7 @@ The `exports` and `imports` field in package.json is now supported. Yarn PnP is supported natively. -See more details in [package exports](/guides/package-exports/). +See more details in [package exports](/guides/modules-and-dependencies/package-exports). ## Major Changes: Development Experience diff --git a/pages/blog/posts/2026-02-03-webpack-5-105.md b/pages/blog/posts/2026-02-03-webpack-5-105.md index 67c7c04b..125f6b15 100644 --- a/pages/blog/posts/2026-02-03-webpack-5-105.md +++ b/pages/blog/posts/2026-02-03-webpack-5-105.md @@ -28,7 +28,7 @@ Webpack 5.105 brings several improvements, both in code generation and bug fixes 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`](/configuration/experiments/#experimentsbuildhttp) option. +[`experiments.buildHttp`](/docs/api/options#experimentsbuildhttp) option. ### Affected CVEs: @@ -107,8 +107,6 @@ For example, in `package.json`: Now, when importing the `foo` package inside a Worker, Webpack will automatically choose the `index.worker.js` file according to the export conditions: -{/_ eslint-disable _/} - ```js // This import is inside a Worker context, so Webpack uses index.worker.js const worker = new Worker(new URL('foo', import.meta.url), { @@ -116,8 +114,6 @@ const worker = new Worker(new URL('foo', import.meta.url), { }); ``` -{/_ eslint-enable _/} - ## 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”. @@ -138,18 +134,14 @@ if (React.useId) { 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. -{/_ eslint-disable _/} - ```text const file = Math.random() > 0.5 ? "a.js" : "b.js"; import.defer("./dir/" + file); ``` -{/_ eslint-enabled _/} - ## Preserving Custom `import.meta` Properties -Webpack now preserves custom `import.meta` properties during bundling when [`output.module`](/configuration/output/#outputmodule) 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. +Webpack now preserves custom `import.meta` properties during bundling when [`output.module`](/docs/api/options#outputmodule) 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. @@ -160,7 +152,7 @@ if (!import.meta.UNKNOWN_PROPERTY) { } ``` -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`](/configuration/module/#moduleparserjavascriptimportmeta) as 'preserve-unknown' in your `webpack.config.js`: +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`](/docs/api/options#moduleparserjavascriptimportmeta) as 'preserve-unknown' in your `webpack.config.js`: ```js // webpack.config.js @@ -210,13 +202,13 @@ module.exports = { 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](/configuration/experiments/#experimentscss), as it gives you greater control over the debugging process and improves integration with external tools. +This new option is especially useful if you are using Webpack’s [experimental CSS compilation feature](/docs/api/options#experimentscss), 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`](/configuration/output/#outputmodule) 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. +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`](/docs/api/options#outputmodule) 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 diff --git a/pages/blog/posts/2026-02-04-roadmap-2026.md b/pages/blog/posts/2026-02-04-roadmap-2026.md index b7239e48..01043e63 100644 --- a/pages/blog/posts/2026-02-04-roadmap-2026.md +++ b/pages/blog/posts/2026-02-04-roadmap-2026.md @@ -22,7 +22,7 @@ Below, we’ll walk through the main areas we’re actively working on and the i ### [webpack#14893](https://github.com/webpack/webpack/issues/14893) - Support for CSS Modules without the need for plugins -There is currently an [`experimental.css`](/configuration/experiments/#experimentscss) option, which enables **native CSS support** without the need to add plugins to your configuration, as was previously required with plugins like [`mini-css-extract-plugin`](/plugins/mini-css-extract-plugin). +There is currently an [`experimental.css`](/docs/api/options#experimentscss) option, which enables **native CSS support** without the need to add plugins to your configuration, as was previously required with plugins like [`mini-css-extract-plugin`](/docs/plugins/mini-css-extract-plugin). The development is already quite advanced, with the possibility of finishing the inclusion into webpack core around **February/March**. After that, the support would remain _experimental_ for a while to gather bug reports, but in **webpack 6** it will no longer be experimental and **plugins for this task will no longer be necessary**. @@ -40,11 +40,11 @@ You can also join the discussion about [universal target](https://github.com/web ### Support for building TypeScript without loaders -Recently, in version [5.105](/blog/2026-02-03-webpack-5-105/) we included support for **resolving the paths defined in the TypeScript configuration**, eliminating the need to use a plugin ([tsconfig-paths-webpack-plugin](https://www.npmjs.com/package/tsconfig-paths-webpack-plugin)). Now we want to further expand TypeScript support by **removing the need to use a loader** (the most common one being _ts-loader_) to transpile TypeScript directly in webpack, which would also **reduce your project’s dependencies**. +Recently, in version [5.105](/blog/posts/2026-02-03-webpack-5-105) we included support for **resolving the paths defined in the TypeScript configuration**, eliminating the need to use a plugin ([tsconfig-paths-webpack-plugin](https://www.npmjs.com/package/tsconfig-paths-webpack-plugin)). Now we want to further expand TypeScript support by **removing the need to use a loader** (the most common one being _ts-loader_) to transpile TypeScript directly in webpack, which would also **reduce your project’s dependencies**. ### [webpack#536](https://github.com/webpack/webpack/issues/536) - Import HTML files and use them as entry points without the need for plugins -Currently, to import HTML files and use them as entry points, it’s necessary to use a plugin ([_html-webpack-plugin_](/plugins/html-webpack-plugin)). The idea is to **integrate that plugin into the core of webpack itself**, similar to how CSS Modules are being handled, and remove the need for a plugin for such a common task. Like CSS Modules, this would be introduced as an _experimental option_, so that in **webpack 6** you’ll be able to remove that dependency. +Currently, to import HTML files and use them as entry points, it’s necessary to use a plugin ([_html-webpack-plugin_](https://github.com/jantimon/html-webpack-plugin)). The idea is to **integrate that plugin into the core of webpack itself**, similar to how CSS Modules are being handled, and remove the need for a plugin for such a common task. Like CSS Modules, this would be introduced as an _experimental option_, so that in **webpack 6** you’ll be able to remove that dependency. You can follow the idea and its progress in the related issue ([#536](https://github.com/webpack/webpack/issues/536)). diff --git a/pages/blog/posts/2026-04-08-webpack-5-106.md b/pages/blog/posts/2026-04-08-webpack-5-106.md index 76da14f5..8389a647 100644 --- a/pages/blog/posts/2026-04-08-webpack-5-106.md +++ b/pages/blog/posts/2026-04-08-webpack-5-106.md @@ -26,7 +26,7 @@ Explore what's new in this release: ## Plugin Validation with `compiler.hooks.validate` -Webpack adds a new top-level `validate` option and a [`compiler.hooks.validate`](/api/compiler-hooks/#validate) hook that standardize how schema validation works across webpack configuration, plugins, and loaders. +Webpack adds a new top-level `validate` option and a [`compiler.hooks.validate`](/docs/api/compilation/Compiler#validate) hook that standardize how schema validation works across webpack configuration, plugins, and loaders. Until now, there was no unified way for plugins to integrate schema validation into the webpack build lifecycle. Each plugin handled validation on its own. The new `compiler.hooks.validate` hook gives plugin authors a standard API to register their validation logic, and `compiler.validate(...)` to run it. This means all validation from webpack's core config to every plugin that adopts the hook is controlled by a single `validate` flag and follows the same patterns: diff --git a/pages/blog/posts/2026-05-19-webpack-5-107.md b/pages/blog/posts/2026-05-19-webpack-5-107.md index 7900bdf1..d16ceb43 100644 --- a/pages/blog/posts/2026-05-19-webpack-5-107.md +++ b/pages/blog/posts/2026-05-19-webpack-5-107.md @@ -170,7 +170,7 @@ The comment value is parsed with the same context the JS and CSS parsers use, so > [!WARNING] > **This feature is experimental and depends on a recent Node.js.** It requires Node.js 22.6 or later for the stable `module.stripTypeScriptTypes` API. The transform handles only erasable TypeScript syntax (see limitations below). For anything else, keep using `ts-loader` or `swc-loader`. -Webpack 5.107 adds first-class TypeScript support behind a new `experiments.typescript` flag. With it enabled, webpack compiles `.ts`, `.cts`, and `.mts` files directly through Node.js's built-in [`module.stripTypeScriptTypes`](https://nodejs.org/api/module.html#modulestriptypescripttypescode-options), no external loader required. The flag is also turned on automatically by [`experiments.futureDefaults`](/configuration/experiments/#experimentsfuturedefaults). +Webpack 5.107 adds first-class TypeScript support behind a new `experiments.typescript` flag. With it enabled, webpack compiles `.ts`, `.cts`, and `.mts` files directly through Node.js's built-in [`module.stripTypeScriptTypes`](https://nodejs.org/api/module.html#modulestriptypescripttypescode-options), no external loader required. The flag is also turned on automatically by [`experiments.futureDefaults`](/docs/api/options#experimentsfuturedefaults). ```js // webpack.config.js @@ -437,8 +437,6 @@ One related improvement: the same external imported with two different phases (o Webpack now supports the [`#__NO_SIDE_EFFECTS__`](https://github.com/javascript-compiler-hints/compiler-notations-spec/blob/main/no-side-effects-notation-spec.md#2-const-variable-declaration) annotation to mark functions as pure for better tree shaking. Calls to functions annotated this way can be eliminated from the bundle when their return value is unused, even if the function body is not statically analyzable as pure. -{/_ eslint-disable _/} - ```js // utils.js /*#__NO_SIDE_EFFECTS__*/ @@ -451,8 +449,6 @@ export function realWork() { } ``` -{/_ eslint-enable _/} - ```js // app.js import { createLogger, realWork } from './utils'; diff --git a/pages/blog/posts/2026-06-25-webpack-5-108.md b/pages/blog/posts/2026-06-25-webpack-5-108.md new file mode 100644 index 00000000..92edec87 --- /dev/null +++ b/pages/blog/posts/2026-06-25-webpack-5-108.md @@ -0,0 +1,375 @@ +--- +title: Webpack 5.108 +layout: post +date: 2026-06-25T00:00:00Z +authors: bjohansebas +category: Release +image: /assets/blog/cover-3.svg +description: Webpack 5.108 introduces a universal target that adapts one bundle to every runtime, HTML entry points with hot reloading, and a substantial round of tree shaking improvements. +--- + +# Webpack 5.108 + +Webpack 5.108 is out, and it pushes two big stories forward. The headline is a brand-new `universal` target: a single preset that compiles one bundle which adapts at runtime to the browser, web workers, Node.js, Electron, and NW.js, replacing the hand-written `target: ['web', 'node']` setups people have been maintaining for years. The release also continues the native HTML work that started in 5.107: a `.html` file can now be used directly as an `entry`, webpack can emit an HTML file for plain JavaScript entries, and HTML modules now support Hot Module Replacement. + +Around those headlines, this release lands a substantial round of tree-shaking improvements (a new `optimization.inlineExports`, cross-module purity, and CommonJS re-export analysis), modernizes the code webpack generates for capable targets, and adds a typed `defineConfig` helper. + +Both the HTML and `universal` features are experimental and live behind opt-in flags, but the direction stays the same as 5.107: you should eventually be able to build a complete web app with zero extra loaders or plugins for HTML, CSS, and TypeScript. + +Explore what's new: + +- [**The `universal` target**](#the-universal-target) +- [**Bun and Deno targets**](#bun-and-deno-targets) +- [**HTML modules: entry points and HMR**](#html-modules-entry-points-and-hmr) + - [HTML as an entry point](#html-as-an-entry-point) + - [HTML output for JavaScript entries](#html-output-for-javascript-entries) + - [Hot Module Replacement](#hot-module-replacement) + - [Customizing the HTML parser](#customizing-the-html-parser) +- [**CSS improvements**](#css-improvements) + - [`url()` inside HTML `style` attributes](#url-inside-html-style-attributes) + - [CSS in Node for universal builds](#css-in-node-for-universal-builds) +- [**Tree shaking**](#tree-shaking) + - [`optimization.inlineExports`](#optimizationinlineexports) + - [Cross-module dead-branch skipping](#cross-module-dead-branch-skipping) + - [Cross-module purity](#cross-module-purity) + - [CommonJS re-exports via `Object.defineProperty`](#commonjs-re-exports-via-objectdefineproperty) +- [**Automatic ES module detection**](#automatic-es-module-detection) +- [**Output and runtime**](#output-and-runtime) + - [Modern syntax in generated code](#modern-syntax-in-generated-code) + - [`output.strictModuleResolution`](#outputstrictmoduleresolution) + - [`[uniquename]` template placeholder](#uniquename-template-placeholder) + - [Worker chunk filenames](#worker-chunk-filenames) +- [**Typed configuration with `defineConfig`**](#typed-configuration-with-defineconfig) +- [**Bug fixes**](#bug-fixes) + +## The `universal` target + +Building code that runs in more than one environment used to mean hand-writing `target: ['web', 'node']` and then dealing with the rough edges yourself: choosing a chunk format that loads everywhere, wiring up a global object, and guarding every platform-specific API by hand. Webpack 5.108 turns that into a single preset. + +```js displayName="webpack.config.js" +export default { + target: 'universal', +}; +``` + +[`target: 'universal'`](/docs/api/options#target) combines the `web`, `web worker`, `node`, `electron`, and `nwjs` platforms into one target and leaves each platform flag _neutral_ instead of locking the bundle to a single environment. Rather than compiling separate web and node bundles, you ship one bundle that figures out its surroundings at runtime and uses whatever the current platform provides. + +A bundle that has to load equally well in a browser and in Node needs a portable module format, so universal builds always output ECMAScript modules: [`experiments.outputModule`](/docs/api/options#experimentsoutputmodule) defaults to `true`, synchronous `require` is turned off, and Node's built-in modules stay available (resolved at runtime through ESM). [`output.globalObject`](/docs/api/options#outputglobalobject) also defaults to `globalThis` so runtime code has one global to reach for on every platform. + +To make a single bundle behave correctly everywhere, several pieces were made platform-aware and now branch on feature detection at runtime instead of being fixed at build time: + +- **Workers**: `new Worker(new URL(...))` resolves the `Worker` constructor from `worker_threads` in Node and from the global `Worker` on the web, so the same worker entry runs in both. +- **Externals**: `commonjs` and `node-commonjs` externals work from the ESM output (loaded defensively via `createRequire` obtained from `process.getBuiltinModule`, guarded so they never break in the browser), and `global` externals resolve against `globalThis`. Electron externals use `module-import` when the target supports ESM. +- **CSS for SSR**: on the server, where there is no DOM to inject into, styles are collected into a registry an SSR host can read (see [CSS in Node for universal builds](#css-in-node-for-universal-builds)). + +Plugins and loaders can detect a universal build at compile time through `compiler.platform.universal`, which is also `true` for the equivalent `target: ['web', 'node']`. + +For a complete, runnable setup, see the [`universal` example](https://github.com/webpack/webpack/tree/main/examples/universal) in the webpack repository. + +## Bun and Deno targets + +Alongside `universal`, webpack 5.108 adds dedicated presets for two newer JavaScript runtimes. Each one configures ESM output and marks the runtime's own built-in modules as externals (so they're left for the runtime to provide instead of being bundled), which previously you had to set up by hand. + +[`target: 'bun'`](/docs/api/options#target) builds for Bun, externalizing Bun's own `bun:*` modules and the Node.js built-ins it provides instead of bundling them. + +```js displayName="webpack.config.js" +export default { + target: 'bun', +}; +``` + +[`target: 'deno'`](/docs/api/options#target) builds for Deno. It resolves Node.js built-ins through the `node:` specifier that Deno requires, and keeps Deno's own import protocols (`npm:`, `jsr:`, `node:`, and `http(s)://` URLs) external so the runtime loads them. Like webpack's other version-aware targets, it accepts a version such as `deno2` or `deno1.40`. + +```js displayName="webpack.config.js" +export default { + target: 'deno', // also 'deno2', 'deno1.40', … +}; +``` + +## HTML modules: entry points and HMR + +> [!WARNING] +> **This feature is experimental and partial.** Webpack 5.107 implemented the `html-loader` side of the story: importing an HTML file from JavaScript runs its tag references through the webpack pipeline. Webpack 5.108 adds the ability to use a `.html` file as an `entry`. Full parity with `html-webpack-plugin` is still in progress; the overall effort is tracked in issue [#536](https://github.com/webpack/webpack/issues/536). + +### HTML as an entry point + +With [`experiments.html`](/docs/api/options#experimentshtml) enabled, you can now point `entry` directly at an HTML file. Its `