Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

webpack 5 <-> html-webpack-plugin 5 #1527

Closed
23 tasks done
jantimon opened this issue Oct 13, 2020 · 128 comments
Closed
23 tasks done

webpack 5 <-> html-webpack-plugin 5 #1527

jantimon opened this issue Oct 13, 2020 · 128 comments
Assignees

Comments

@jantimon
Copy link
Owner

jantimon commented Oct 13, 2020

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:

current blockers (help needed by the webpack team):

current alpha playround:

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

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
Copy link

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
Copy link

good news, waiting 👍

@tianyingchun
Copy link

and When is it expected to be released?

@jantimon
Copy link
Owner Author

@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
Copy link

jeffposnick commented Oct 14, 2020

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
Copy link

💯 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
Copy link
Owner Author

@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
Copy link
Owner Author

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

@jantimon
Copy link
Owner Author

I pushed the current version as html-webpack-plugin@5.0.0-alpha.1 which you should be able to install with html-webpack-plugin@next

@jantimon
Copy link
Owner Author

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

@jantimon
Copy link
Owner Author

jantimon commented Oct 16, 2020

I have just released html-webpack-plugin@5.0.0-alpha.2 (which requires webpack 5.1.2) - it is now adding the assets the right way @jeffposnick could you please try it once again?

@tianyingchun
Copy link

@jantimon
i tried webpack@5.1.2 & html-webpack-plugin@5.0.0-alpha.2 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
Copy link
Owner Author

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 html-webpack-plugin@5.0.0-alpha.3 ?

@Thebarda
Copy link

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 html-webpack-plugin@5.0.0-alpha.3 ?

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

@tianyingchun
Copy link

@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
Copy link
Owner Author

@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
Copy link

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

@tianyingchun
Copy link

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

@serprex
Copy link

serprex commented Oct 24, 2020

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

@cjblomqvist
Copy link

cjblomqvist commented Dec 23, 2020

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
Copy link
Owner Author

jantimon commented Dec 24, 2020

@jantimon
Copy link
Owner Author

jantimon commented Jan 4, 2021

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
Copy link
Contributor

AviVahl commented Jan 4, 2021

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

@smorimoto
Copy link

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

@Thebarda
Copy link

Thebarda commented Jan 5, 2021

Hello @jantimon, I have some issues with html-webpack-harddisk-plugin along side html-webpack-plugin@5.0.0-beta.4.
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
Copy link
Owner Author

jantimon commented Jan 6, 2021

@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
Copy link

Thebarda commented Jan 6, 2021

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
Copy link

FYI for anyone interested, webpack/webpack#12283 was resolved in webpack@5.12.0.

@jantimon
Copy link
Owner Author

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

@vputsenko
Copy link

vputsenko commented Jan 13, 2021

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

@raix
Copy link

raix commented Jan 19, 2021

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

@hayes
Copy link

hayes commented Jan 22, 2021

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

@slavafomin
Copy link

@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
Copy link
Owner Author

jantimon commented Feb 3, 2021

released as html-webpack-plugin 5.0.0

@olegKusov
Copy link

released as html-webpack-plugin 5.0.0

please add info in release that it supports webpack 5.

@csvan
Copy link

csvan commented Jul 23, 2021

@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

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

No branches or pull requests