feat(html): add output.html to generate HTML for non-HTML entrypoints#21125
feat(html): add output.html to generate HTML for non-HTML entrypoints#21125aryanraj45 wants to merge 2 commits into
Conversation
|
|
@alexander-akait could u please have a look here implemented output.html to generate HTML for non-HTML entrypoints with JS/CSS chunk injection ask co-pilot to review ? Thanks! |
| } | ||
| } | ||
|
|
||
| module.exports = OutputHtmlPlugin; |
There was a problem hiding this comment.
This is wrong solution, we should not add a new plugin, when output.html is true we should wrap all entrypoints (js or css) in html file, like we have entry: "./index.html", so template option will work and other things will work too, we already have logic about how to handle css, js and etc
Also we should support html in entry description option, so developer can set by entries where generate html where no
There was a problem hiding this comment.
Ohh yeah, thanks for the direction! I went through the existing HTML pipeline publicPath is already handled by the generator, and the template gets reused automatically. So no other option needed for them in future as discussed. Got it, thanks!
alexander-akait
left a comment
There was a problem hiding this comment.
We should revisit architecture
67ed96f to
11a537c
Compare
|
@alexander-akait Done as discussed no new plugin. Each non-HTML entry is wrapped into a synthetic HTML entry through the existing pipeline (JS/CSS injection, publicPath, template all work). Also added One thing: the synthetic entry also emits a |
ca99e42 to
9aba257
Compare
|
@alexander-akait could you please have a re-look :)) |
When output.html (or an entry's `html` option) is enabled, the entrypoint is wrapped in a synthetic HTML module (<script src> for JS, <link> for CSS) that flows through the existing HtmlModulesPlugin/HtmlGenerator pipeline, so chunk injection, publicPath and the template option work like a real `entry: "./index.html"`. Adds `html` to the entry descriptor for per-entry control.
9aba257 to
26510f5
Compare
alexander-akait
left a comment
There was a problem hiding this comment.
Let’s make it smarter, let’s add a hook for entry option plugin and use this hook in html webpack plugin, it will be more plugable, also other developers can use it to
Implement custom logic for non html files, for example for markdown
Move the output.html entry-wrapping logic out of EntryOptionPlugin into a tap on a new EntryOptionPlugin.getHooks(compiler).entry SyncBailHook, and register it from HtmlModulesPlugin. Other plugins can now redirect a non-HTML entry to a custom request (e.g. markdown).
|
@alexander-akait done Added an EntryOptionPlugin.getHooks().entry SyncBailHook and moved the |
Summary
When
output.htmlis true webpack emits an HTML file for every non-HTML entrypoint and injects the entrypoint's initial JS and CSS chunks. JS chunks are injected as deferred scripts (ortype="module"for ESM output) at the end of<body>; CSS chunks as<link rel="stylesheet">in<head>. HTML entries are left toHtmlModulesPluginand are not duplicated. This is part of theexperiments.htmlroadmap — bringinghtml-webpack-pluginabilities into webpack core.What kind of change does this PR introduce?
feat
Did you add tests for your changes?
Yes —
test/OutputHtmlPlugin.unittest.js(6 unit tests: default-off, JS inject, publicPath, ESM output, XSS escaping, HTML-entry skip) andtest/configCases/output-html/(2 integration cases).Does this PR introduce a breaking change?
No.
output.htmldefaults tofalse.If relevant, what needs to be documented once your changes are merged or what have you already documented?
output.htmloption should be added to the webpack configuration docs.Use of AI
Claude Code was used to assist with implementation, test scaffolding, and lint fixes. All logic was reviewed, tested, and validated manually per the webpack AI policy.