Use original filename without .gz extension

[gilesbutler]

• Operating System:
  OSX Mojave 10.14

• Node Version:
  v8.11.4

• NPM Version:
  6.8.0

• webpack Version:
  4.17.1

• webpack-defaults Version:
  Unknown

Expected Behavior

To be able to use [file] for the filename prop and it return the original filename without the .gz extension

Actual Behavior

There is no output

Code

  {
          filename: "[file]",
          algorithm: "gzip",
          test: new RegExp("\\.(" + productionGzipExtensions.join("|") + ")$"),
          threshold: 0,
          minRatio: 1,
          deleteOriginalAssets: true
    }

As background we're using S3 to host static assets and you have to upload the asset without the .gz extension.

I was trying to use the filename function to hack together what I needed, something like this...

filename(info) {
    // info.file is the original asset filename
    // info.path is the path of the original asset
    // info.query is the query

    // The extension (info.path) is coming through as part of the filename so we need to remove it to get correct filenames for S3
    const filename = info.file.replace(info.path, "");
    return `${filename}.${info.path}`;
},

But then the output folders come out as .js and .css. For some reason they have a proceeding .

Using the filename function and logging the info param I get the following...

  { 
    file: 'js/app.25450252.js',
    path: 'js/app.25450252.js',
    query: '' 
}

Seems like path and file are returning the same thing.

How Do We Reproduce?

You can test it by setting filename: "[file]".

Sorry if I'm missing something blatantly obvious!!

[alexander-akait]

You want to generate assets without gz extension right? What is use case?

[gilesbutler]

Hey @evilebottnawi

Yep that's correct.

As background we're using S3 to host static assets and you have to upload the asset without the .gz extension.

S3 requires you to gzip your assets then remove the extension so index.js.gz should become index.js

[alexander-akait]

@gilesbutler Can you provide link on this strange behavior? We can implement this, but this is very misleading and strange

[gilesbutler]

@evilebottnawi that's what I thought too and then came across this... (https://stackoverflow.com/questions/8080824/how-to-serve-gzipped-assets-from-amazon-s3)[https://stackoverflow.com/questions/8080824/how-to-serve-gzipped-assets-from-amazon-s3]

In doing a bit more research though I've found that CloudFront can compress the assets for me rather than having to use this plugin so I'll go down that route. I wouldn't worry about adding support for this if it's strange behaviour, thanks for your help.

[wood1986]

Is it possible to reopen this and request this feature?

My use case is akamai support brotli compression from origin. See https://developer.akamai.com/blog/2018/04/16/brotli-from-origin/. if I do not use this and ask akamai to compress for us automatically, we need to update the plan (need more money) and it takes time.

The thing is if I do not do this and output js.br, how the html-webpack-plugin works to use the brotli version? Or you can say I can route all js to js.br on the akamai portal. But I do not have access

[andrerivas]

Can we open this? This is needed for S3.

https://stackoverflow.com/questions/8080824/how-to-serve-gzipped-assets-from-amazon-s3

[HoneyMiri]

Need this as well for S3.. Thank you 🙏

[alexander-akait]

okay, open as feature, PR welcome