webpack 5 <-> html-webpack-plugin 5

[jantimon]

Finally Webpack 5 has been released! 👍

During the beta I tried to provide a html-webpack-plugin version which is compatible to webpack 4 and webpack 5.
As there have been some API and typing changes in webpack 5 this approach is limited.

To provide the best possible webpack 5 support I have started on a dedicated webpack 5 version of the html-webpack-plugin.

current progress:

• drop webpack 4 support

• drop node < 10 like webpack

• make use of Compiler.hook.initialize to get the latest options

• update typings for webpack 5

• fix scriptLoading defer for inject false

• make scriptLoading defer the default

• add assets in Compilation.PROCESS_ASSETS_STAGE_ADDITIONAL (see Guidance on porting a plugin to webpack v5? webpack/webpack#11425 (comment) )

• add assets with new api compilation.emitAsset (Strange asset name when used with webpack v5.0.0-rc.3 #1522)

• use new webpack.sources.RawSource(html) to create assets

• add support for [name]

• provide options and output name in all hooks

• allow filename to be a function

• emitAssets even if they have been generated in a previous compilation (to fix index.html disappear with watch mode (HtmlWebpackPlugin) #1476 and html was not generated in watch mode, after changing one of the files #1432)

• use compiler.webpack.LibraryTemplatePlugin

• verify support for raw-loader (blocked by Webpack 5 - child compiler ignores library target / name options webpack/webpack#11909)

• remove @types/tapable as it is included in tapable 2

• provide a publicPath to the child compiler to add support for publicPath: 'auto' & 'asset/resource' (assets modules won't work for inline html <img> webpack/webpack#11968 (comment))

• use the correct stage to allow sri and service worker generation (blocked by Extend Webpack Compilation Stages webpack/webpack#11822)

• fix error reporting (which is currently breaking the travis build)

• use the html-webpack-plugin publicPath option also for the template child compilation

• remove html-minification (if a separate plugin which covers the html minification is available) (postponed)

current blockers (help needed by the webpack team):

• webpack/issues/11822
• webpack/issues/11909
• Missing queryString for inline entries like data:text/javascript,console.log("demo") webpack/webpack#12214

current alpha playround:

CodeSandbox of the html-webpack-plugin 5.0.0-alpha.17

Most of the work is done just by me in my spare time for fun - so if this work helps you feel free to buy me a beer 🍺

[jeffposnick]

FWIW, webpack v4.40.0 added the new Asset API, so you may not have to drop webpack v4.x support completely, if you require that users update to at least that version.

(It's still pretty inconvenient to have to hook into the compilation in two fundamentally different ways, depending on whether you're using webpack v4.x or webpack v5.x, though.)

[tianyingchun]

good news, waiting 👍

[tianyingchun]

and When is it expected to be released？

[jantimon]

@jeffposnick I have an idea to fix your issue - can you please try the next branch?

Instead of extracting the result of the child compiler it will now extract the assets inside a child compiler hook:

const extractedAssets = [];
      childCompiler.hooks.compilation.tap('HtmlWebpackPlugin', (compilation) => {
        compilation.hooks.processAssets.tap(
          {
            name: 'HtmlWebpackPlugin',
            stage: Compilation.PROCESS_ASSETS_STAGE_ADDITIONS
          },
          (assets) => {
            temporaryTemplateNames.forEach((temporaryTemplateName) => {
              if (assets[temporaryTemplateName]) {
                extractedAssets.push(assets[temporaryTemplateName]);
                compilation.deleteAsset(temporaryTemplateName);
              }
            });
          }
        );
      });

@tianyingchun hard to say - depends a little bit on my time :)

[jeffposnick]

I'm seeing different behavior, but not having luck getting access to the assets created by html-webpack-plugin from within my plugin yet. I'm using the following devDependencies:

"html-webpack-plugin": "github:jantimon/html-webpack-plugin#next",
"webpack": "webpack@^5.1.0"

First off, I see the following originating from html-webpack-plugin:

(node:79288) [DEP_WEBPACK_COMPILATION_ASSETS] DeprecationWarning: Compilation.assets will be frozen in future, all modifications are deprecated.
BREAKING CHANGE: No more changes should happen to Compilation.assets after sealing the Compilation.
        Do changes to assets earlier, e. g. in Compilation.hooks.processAssets.
        Make sure to select an appropriate stage from Compilation.PROCESS_ASSETS_STAGE_*.

And at the time my plugin runs, I don't see the expected index.html in either the main compilation's assets, or the child compilation's assets. (So this part is different in the next branch, as I was previously seeing the incorrectly named index.html in the child compilation's assets.)

I am curious as to whether you really need to go through the steps of deleting your assets from the child compilation and adding them to the parent compilation—maybe someone from the webpack team could weigh in on the best practice? There is a mode in the plugin that I support in which a child compilation is performed (independent of the logic related to getting a list of all the assets), and I just leave the assets it creates as part of the child compilation, and don't attempt to "move" them to the parent compilation.

My plugin, at least, already iterates over both the parent and any child compilations to get the asset list from each.

[tianyingchun]

💯 My projects totally want to upgrade to webpack@5 exception html-webpack-plugin cause of i have some cusomized html plugin based on the hooks of html-webpack-plugin if you have ready for html-webpack-plugin@next i can install as devDeps to do some testings works. :)

[jantimon]

@jeffposnick okay good to know that the temporary file disappeared - now I just need to use the same api to add it once again.

Deleting the compiled template from the child compilation as it will be processed even further before it is added again with the final name. It also allows to compile a template only once even if it is used to generate multiple html files.

[jantimon]

There seems to be a blocker - if I move the asset additions away from the emit phase the child compilation is not done.

[jantimon]

I pushed the current version as [email protected] which you should be able to install with html-webpack-plugin@next

[jantimon]

Wow @sokra improved the deleteAsset function webpack/webpack#11704 so now we can use thisCompilation for the child compiler. 👍

[jantimon]

I have just released [email protected] (which requires webpack 5.1.2) - it is now adding the assets the right way @jeffposnick could you please try it once again?

[tianyingchun]

@jantimon
i tried [email protected] & [email protected] it also throw error

(node:48122) [DEP_WEBPACK_COMPILATION_ASSETS] DeprecationWarning: Compilation.assets will be frozen in future, all modifications are deprecated.
BREAKING CHANGE: No more changes should happen to Compilation.assets after sealing the Compilation.
        Do changes to assets earlier, e. g. in Compilation.hooks.processAssets.
        Make sure to select an appropriate stage from Compilation.PROCESS_ASSETS_STAGE_*.

TypeError: The 'compilation' argument must be an instance of Compilation

[jantimon]

Thanks for testing @tianyingchun - it looks like this release didn't include all changes - can you please try one more time with Now it's part of [email protected] ?

[Thebarda]

Thanks for testing @tianyingchun - it looks like this release didn't include all changes - can you please try one more time with Now it's part of [email protected] ?

I don't have this problem anymore. Well done 👍

[tianyingchun]

@jantimon yes the [DEP_WEBPACK_COMPILATION_ASSETS] DeprecationWarning has disappeared. but have another questions about the hooks of html-webpack-plugin i write a plugin based on the hooks thisCompilation as bellow

apply(compiler: Compiler): void { 
    compiler.hooks.thisCompilation.tap(this.pluginName, (compilation) => {
      compilation.mainTemplate.hooks.requireExtensions.tap(this.pluginName, () => {
....

finnally it give an error

TypeError: The 'compilation' argument must be an instance of Compilation

[jantimon]

@tianyingchun I am not sure how this would be connected to the html-webpack-plugin.. if it is could you please open a new issue for that part?

[tianyingchun]

ok， i will research this issue first, thanks very much. 👍

[tianyingchun]

alpha-5 still can not success build it throws error like https://github.com/jantimon/html-webpack-plugin/issues/1451

[serprex]

alpha.6 is working fine with my simple webconfig. I say simple since 4.5.0 also was working while using webpack 5

[cjblomqvist]

For me it seems inject: false isn't properly respected - I still get script tags (in headTags).

PS. Sorry for not having a proper repro (no time), but I thought it be nice for everybody to hear about it anyway.
PS2. Otherwise it seems to work great (for my quite weird case). Possibly also favicons plugin which is really nice since it's still more unproven!

[jantimon]

@cjblomqvist as you can see inject: false doesn't inject anything:

https://html-webpack-plugin.js.org/?code=new%20HtmlWebpackPlugin(%7B%0A%20%20%20inject%3A%20false%0A%7D)%0A

[jantimon]

So far the feedback of the beta is quite good - there is only one bigger bug which seems to be caused by a webpack bug. (webpack/webpack#12283)
The webpack core team is already working on it so it will probably disappear soon :)

@AviVahl thanks for your feedback 5.0.0-beta.4 is now using ^2.0.0 :)

[AviVahl]

beta.4 works well from my end. Thanks for the fixes ❤️

[smorimoto]

Very very cool progress @jantimon! Thank you so much!

[Thebarda]

Hello @jantimon, I have some issues with html-webpack-harddisk-plugin along side [email protected].
Here is my configuration :

   new HtmlWebpackPlugin({
      alwaysWriteToDisk: true,
      template: './www/front_src/public/index.html',
      filename: 'index.html',
    }),
    new HtmlWebpackHarddiskPlugin({
      outputPath: path.resolve(`${__dirname}/www`),
    }),

In production mode, I generates 2 index.html files. So first one is generated at the right place (following my outputPath) but it contains the wrong link to my CSS files. The other is generated at the same place as my static JS and CSS files and it contains the good links to my CSS files.

I hope I was clear enough :)

[jantimon]

@Thebarda thanks for you feedback - can you please create an issue directly for the html-webpack-hardisk-plugin with a little bit more info which css urls you would expect and which you get instead?

[Thebarda]

FYI, I fixed it by moving the file path into filename

   new HtmlWebpackPlugin({
      alwaysWriteToDisk: true,
      template: './www/front_src/public/index.html',
      filename: path.resolve(`${__dirname}/www/index.html`)',
    }),
    new HtmlWebpackHarddiskPlugin(),

It produces an HTML file at the right place with the right hash inside CSS urls

[joealden]

FYI for anyone interested, webpack/webpack#12283 was resolved in [email protected].

[jantimon]

It looks like everything works well so I will release html-webpack-plugin 5.x as a stable release soon

[vputsenko]

Ok, then just press "merge" button :) we are getting DEP_WEBPACK_COMPILATION_ASSETS with current version. Thank you!

[raix]

@jantimon sounds good - any issues blocking the v5 release?

[hayes]

looks like webpack 5 support was merged to master yesterday but has not been released, is that intentional?

[slavafomin]

@jantimon thank you for your amazing work. I guess we are all looking forward for the release. Would love to see this nasty DEP_WEBPACK_COMPILATION_ASSETS warning to go away :)

Is there anything that blocks the release right now? We are using only the small subset of the plugin features, but I've tried the 5.0.0-beta.6 version and it works great for us.

[jantimon]

released as html-webpack-plugin 5.0.0

[olegKusov]

released as html-webpack-plugin 5.0.0

please add info in release that it supports webpack 5.

[csvan]

@olegKusov it's already in the changelog: https://github.com/jantimon/html-webpack-plugin/blob/main/CHANGELOG.md#500-2021-02-03

Drop support for webpack 4 and node <= 10 - For older webpack or node versions please use html-webpack-plugin 4.x