Disable hashed URL params in chunk filenames

[siphomateke]

The hashes were causing issues in the zipped output. Since the hashes were only being added to the zipped output, they have been removed entirely.

[adambullmer]

It's entirely possible that in extensions, these hashes for cache busting / fingerprinting aren't necessary, but could you explain a little more about the issue you were having?

[siphomateke]

Sorry, I should have described the issue I was having.

In the zipped output, the JS files have hashes attached to the end of their file names. For example, chunk-vendors.chunk-vendors.js?c6155ba6. If you open the zipped extension in Chrome, you get the error

Failed to load resource: net::ERR_FILE_NOT_FOUND chrome-extension://ndlggceocebjblpfabdlekeijniiagkf/js/chunk-vendors.chunk-vendors.js?c6155ba6

or in Firefox

Loading failed for the <script> with source “moz-extension://1cc29950-82e8-46de-a7a8-71a01878d7af/js/chunk-vendors.chunk-vendors.js?c6155ba6”.

Actually, looking at this again, I think I may have been mistaken that hashes were only being used in the zipped output. The hashes are used in the generated HTML in both outputs but are only appended to filenames in the zipped output.

I'll admit my knowledge of Webpack hashed URL parameters is a bit limited. How are the hashes supposed to work? Is it just a bug that the hashes are being appended to the filenames in the zipped output? If it is, then this pull request can probably be closed and the bug looked into. I just wanted to get vue-cli-plugin-browser-extension to work and felt I should share my fixes.

[adambullmer]

So normally the hashes modify the filename to create a fingerprint. In static site situations, this is desirable as it provides natural cache busting because the end resource name has changed. Ex app.abcd123.js becomes app.123abcd.js on a later deploy. This would allow things like a CDN and a browser to cache resources efficiently.

Initially, I was proceeding with the idea of persisting the hash, but appended on as a query param, so that the generated files have predictable names (background.js -> dist/background.js) and in the rendered HTML, those references looks like <script src="/content-script.js?abcd123"></script> which ought to be a sane URL. This would be to aid the output of the manifest.json by having easier filenames to load.

However since this is for a browser extension, I believe there wouldn't be the same need for caching as the resources likely don't get served from browser cache, and there is no CDN. It's probably fine to disable the asset fingerprinting all together like you have done here.