Skip to content

docs: state what CSS and HTML support is built in, and use it in the guides - #8342

Merged
alexander-akait merged 6 commits into
mainfrom
claude/webpack-docs-migration-guides-q3s7v3
Aug 29, 2026
Merged

docs: state what CSS and HTML support is built in, and use it in the guides#8342
alexander-akait merged 6 commits into
mainfrom
claude/webpack-docs-migration-guides-q3s7v3

Conversation

@alexander-akait

Copy link
Copy Markdown
Member

Summary

Follow-up to #8339. Two problems with what landed there, plus the conversion it left undone.

The loaders and plugins indexes called style-loader, css-loader, html-loader, MiniCssExtractPlugin and HtmlWebpackPlugin deprecated and superseded. That overstates it — the support is experimental, and it does not cover preprocessors, css-loader's importLoaders / localIdentRegExp / getJSON / filter callbacks, style-loader's insert / attributes / styleTagTransform / lazy-singleton injection, html-loader's scriptingEnabled / postprocessor, or html-webpack-plugin's chunksSortMode / xhtml / showErrors / cache and its plugin-hook ecosystem. Each guide now has a What's built-in section stating the scope as two columns, and the index entries link to it instead of declaring the packages dead.

A developer opening /loaders/ also could not tell which capabilities webpack already has, so that page now opens with What needs no loader: JavaScript, JSON, Asset Modules, WebAssembly, and the experimental CSS, HTML and TypeScript support — with the TypeScript caveat that it erases types but does not type-check.

Finally, eight pages that still configured html-webpack-plugin now use output.html: the development, HMR, production, PWA and modern-web-platform guides, the two concepts pages that used the plugin only as an example of what a plugin is, and the CoffeeScript config sample. Each keeps its title through output.html.title and pins the page name with output.htmlFilename, because the default derives it from output.filename ([name].bundle.js would otherwise emit index.bundle.html).

Output management and caching deliberately keep the plugin, with a note saying why. With output.html, the generated page re-enters the entry's script as a new entry named __html_<moduleHash>_<n>, and the named entry chunk is left holding the page's HTML string rather than the application:

asset index.bundle.js            327 bytes   (name: index)              <- the page, not the app
asset __html_63c48ec8_0.bundle.js 69.8 KiB   (name: __html_63c48ec8_0)  <- the app + lodash
asset index.html                 135 bytes

Those two guides are about bundle filenames and [contenthash], so converting them would teach the wrong thing. The other eight only show configuration, so they convert cleanly.

What kind of change does this PR introduce?

docs

Did you add tests for your changes?

No new tests — documentation only. The scope tables were derived from the actual option surface (CssParserOptions, CssGeneratorOptions, CssModuleGeneratorOptions, HtmlParserOptions, HtmlGeneratorOptions) and the built-in list from lib/ModuleTypeConstants.js plus the default rules in lib/config/defaults.js, not from recollection. Every converted config shape was run against webpack 5.110.0, and jest, eslint, prettier and markdownlint all pass.

Does this PR introduce a breaking change?

No.

If relevant, what needs to be documented once your changes are merged or what have you already documented?

n/a — this PR is the documentation.

Use of AI

This PR was prepared with Claude Code. The scope of each built-in was read out of the schemas and lib/ sources and the emitted-output claims were checked by running real builds; the output.html behaviour described above was reproduced from scratch on 5.110.0 before deciding which guides to convert. All output was reviewed before committing.


Generated by Claude Code

The loaders and plugins indexes called style-loader, css-loader,
html-loader, MiniCssExtractPlugin and HtmlWebpackPlugin deprecated and
superseded, which overstates it: the built-in support is experimental and
does not cover preprocessors, css-loader's importLoaders, localIdentRegExp,
getJSON and filter callbacks, style-loader's insert, attributes,
styleTagTransform and lazy/singleton injection, html-loader's
scriptingEnabled and postprocessor, or html-webpack-plugin's chunksSortMode,
xhtml, showErrors, cache and plugin-hook ecosystem.

Add a "What's built-in" section to both guides stating the scope as two
columns, and point the index entries at it instead of declaring the
packages superseded. Also scope the favicon claim: webpack emits the icons
it is given, it does not generate size and format variants.
A developer scanning the loaders list cannot tell which capabilities
webpack already has, so lead with the list of what needs no loader:
JavaScript, JSON, asset modules, WebAssembly, and the experimental CSS,
HTML and TypeScript support.

Shorten the entries added for the CSS and HTML loaders to a single
parenthetical, so the list reads as a list again; the scope of each
built-in stays in the guide it links to.
Move the list above the introduction so it is the first thing on the
page, and fold the closing line into the prose that follows it.
Eight pages now generate their page with output.html instead of the
plugin: the development, HMR, production, PWA and modern web platform
guides, the two concepts pages that used the plugin only as an example of
what a plugin is, and the CoffeeScript configuration sample. Each keeps
its title through output.html.title and pins the page name with
output.htmlFilename, since the default derives it from output.filename.

Output management and caching keep the plugin, with a note saying why:
output.html re-enters the entry's script under an internal chunk name and
leaves the named entry chunk holding the page, so a guide whose subject is
bundle filenames would be teaching the wrong thing.
@vercel

vercel Bot commented Aug 28, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
webpack-js-org Ready Ready Preview Aug 28, 2026 3:30pm

Request Review

bjohansebas
bjohansebas previously approved these changes Aug 28, 2026
Dropping the plugin is only half the change: the configuration has to keep
generating the page. Three examples lost HTML generation entirely when the
plugin was removed — the two concepts pages and the CoffeeScript config —
and the guides that did set output.html leaned on the 'auto' default
instead of saying so.

Every one of them now enables experiments.html and sets output.html, so
each configuration does what it did with the plugin.
Built each converted config both ways and compared the emitted files, which
turned up four mismatches:

- The three examples that passed `template` to the plugin were converted to
  output.html, which generates a bare document and threw the template's lang,
  charset, title and body away. They now use an HTML entry point, which keeps
  the authored page and rewrites its script URL.
- The generated page carried no charset or viewport, which the plugin emits by
  default; output.html.meta now supplies both.
- production emitted app.html and modern web platform emitted a page whose name
  carried the contenthash, because both derive from output.filename. Both now
  pin output.htmlFilename to index.html.
- The multi-entry guides — development, HMR and PWA — emit one page per
  entrypoint instead of the single page the plugin builds, six files where
  there were three, and development prints that file list in six places. They
  keep the plugin, with the same note output management and caching carry.
@alexander-akait
alexander-akait merged commit c2237b9 into main Aug 29, 2026
11 checks passed
@alexander-akait
alexander-akait deleted the claude/webpack-docs-migration-guides-q3s7v3 branch August 29, 2026 11:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants