Same hash is generated for all Sass files

[nradford]

All of the files I'm passing into .sass() are getting the same hash and the hash updates when any of the .scss files contents are changed.

Also, their chunk name in the terminal output is always the same as the first .js() entry in webpack.mix.js.

const mix = require('laravel-mix');
require('laravel-mix-versionhash');

mix
    .sass('resources/assets/sass/vendor.scss', 'public/css')
    .sass('resources/assets/sass/home-page.scss', 'public/css')
    .sass('resources/assets/sass/resources.scss', 'public/css')

    .js('resources/assets/js/vendor.js', 'public/js')
    .js('resources/assets/js/home-page.js', 'public/js')
    .js('resources/assets/js/resources.js', 'public/js')

    .versionHash();

[ctf0]

@Erutan409 did you have this in ur testing ?

[Erutan409]

@ctf0 Yes, but it should only be doing it for CSS files. Which, kind of makes sense since Laravel Mix was seemingly built around shimming in a mock JS file for its entry point if someone just wanted to use webpack for styling compilation (for simplicity sake for the developer). So, it appears as though CSS-related assets are piped through the first JS file being processed within the Laravel MIx/Webpack configuration.

I tested the output before/after the #24 merge - same results.

I don't think this is anything you'd want to mess with, honestly. Given how webpack generates its dependency graph when building all the assets, you'd be asking for more trouble than it's worth for developers referencing dissimilar assets within each other and maintaining any updates to said file names.

If this is a deal-breaker, you may want to jump out of Laravel Mix and start doing some of the config on your own; and I don't make that suggestion lightly.

Other option could be building your own separate webpack config for sass and providing it to Laravel Mix via .webpackConfig().

[nradford]

Using .version() instead of .versionHash() does generate a unique hash for each .css file in the mix-manifest.json file.

{
    "/js/home-page.js": "/js/home-page.js?id=ad2c1e05639528887762",
    "/js/resources.js": "/js/resources.js?id=e448427b8daba57622b7",
    "/js/vendor.js": "/js/vendor.js?id=d077bc20aefbccea26e6",
    "/css/vendor.css": "/css/vendor.css?id=1d9d930cbd13358b4e22",
    "/css/home-page.css": "/css/home-page.css?id=f4bf04afc93a4bcdfe26",
    "/css/resources.css": "/css/resources.css?id=7bc59660552dc6590bec"
}

[Erutan409]

@nradford Yes, but the way Laravel Mix's built-in versioning works is not the same as how this plugin uses webpack to generate the hash from the assets. In fact, using Laravel Mix's built-in hashing is actually what's being leveraged for the recent implementation for mix.combine() support.

So, yeah I can see where that might seem like it should be the same. But, this plugin is versioning a bit differently.

[ctf0]

@nradford can u also test the hashing with version 1.0.8 and reply back if the result are different ?, if so i can make 2 separate versions.

[nradford]

@Erutan409 That makes sense, I didn't realize Mix wasn't using Webpack to generate the hashes.

@ctfo I tested 1.0.8 and the results were the same as 1.1.1.

[ctf0]

@nradford thanks for confirming, if u still think this is a bug & u know a solution plz send a PR,

[Erutan409]

@ctf0 You could strip out webpack hashing and just parse the manifest for its hashed name's, forgoing webpack hashing.

That would be a hefty overhaul, though.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.