Using Compression plugin alongside Html Webpack plugin

[retwedt]

Is it possible to make the Html Webpack plugin insert a link to the .gz build file instead of the normal .js build file?

Is this even the right place to ask this question??

Thanks for your help, and thanks for your work on a great plugin!

[mastilver]

duplicate of #61

It's something that out of your control, you will need to wait for the release of compression-webpack-plugin@1

[retwedt]

Thanks!

[varenya]

has there been a update on this? Looks like the PR for the issue in the compression is merged but still i am not seeing the gzipped file being updated in the script tag.

[thegoldenmule]

Hi there-- any movement here? Using compression-webpack-plugin (1.1.11) and html-webpack-plugin (3.2.0) but the html plugin does not write the gz paths. Several tickets say this is fixed but it does not seem to be.

[jantimon]

The compression-webpack-plugin hooks into the emitphase to find files which should be compressed.

https://github.com/webpack-contrib/compression-webpack-plugin/blob/a389f2dbdda9f084487618d8e8b9e0c210515c33/src/index.js#L148-L154

While the html-webpack-plugin does the same to add the html file to webpack:

html-webpack-plugin/index.js

Line 90 in 75eef88

(compiler.hooks ? compiler.hooks.emit.tapAsync.bind(compiler.hooks.emit, 'HtmlWebpackPlugin') : compiler.plugin.bind(compiler, 'emit'))((compilation, callback) => {

My guess it that you registered compression-webpack-plugin before the html-webpack-plugin so the html file is added after the compression is complete.

To prevent this behaviour we would have to adjust the compression-webpack-plugin as this can't be changed here.

[thegoldenmule]

Thanks for the reply. I'm not quite understanding-- so this bug is not fixed? Or are you saying there is a workaround?

[jantimon]

Please make sure that the html-webpack-plugin is first in your plugins array - then it should work.
If not open an issue for the compression webpack plugin :)

[noobG]

@thegoldenmule

Have same issue, but after looking further into it, I've concluded that this is actually a web server problem; you can't have a .gz source in your script tag src attribute; your web server should be configured to return the gzipped version of your bundle when receiving the request in production mode.

Here is an example way to do it with nginx: http://nginx.org/en/docs/http/ngx_http_gzip_static_module.html

[thegoldenmule]

@jantimon I will try presently.

@noobG This is not a webserver problem. I already have Apache configured to serve with correct headers as I'm serving other assets that way. Regardless of what you name it (.js or .gz), in this case the plugin does not insert the output of the plugin before it. It presents as a bug. The point of an array is to order elements, and in this case you have to unorder them-- a bit of a screwy interface IMO.

[mastilver]

If it's a plugin position issue, we can fix that by using the stage option on tap, see: https://github.com/danethurber/webpack-manifest-plugin/pull/142/files

[jantimon]

@mastilver that's a cool idea

[thegoldenmule]

I tried reordering them, but it had no effect.

[thegoldenmule]

Hi there, I'm unclear on how to proceed. This cannot be an uncommon use case, right? Gzip build -> add script tag? What am I missing?

[noobG]

@thegoldenmule I think the problem is that the webpack plugin pipeline is a series of functions that operate sequentially on the webpack output (correct me if I'm wrong); if this is the case, html-webpack-plugin can't (and shouldn't) assume arbitrary files added by prior plugins are meant to go in the script tag

Did some digging and found the actual place the script tags seem to be inserted, and it looks like the logic is simply to add a script tag for each js asset

https://github.com/jantimon/html-webpack-plugin/blob/master/index.js#L513

[lock]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.