[rollup] css hash changes when js does

[isidrok]

Since css files are named using the chunk file they came from, changing any js file will generate a new hash for that css, even if it didn't change:

/* bar.css */
body { color: green}

/* bar.js */
import './bar.css';
export default 1;

After using rollup we get something like bar-ahash-js and bar-ahash-csshash.css.

If we change bar.js to export default 2; for example, and run rollup again, we will end up with two different files bar-anotherhash.js and bar-anotherhash-csshash.css even when the contents of bar.css did not change.

To fix this we could use the original entry module file instead of the chunk one when creating the file, so the base only changes when changing the name of the entrypoint.

PS: really nice plugin!

[tivac]

This is a good callout of the limitations of the tests, where I disable all the hashing so the output names stay consistent 😞

I'll try to take a look at this tonight, thanks!

[isidrok]

I had a similar use case and ended getting the input files from the options hook and then looking for them in each chunk modules but that doesn't help at all with dynamic imported modules so it may be better to look for outputOptions.entryFileNames / chunkFileNames patterns and so on and do it by regexp.

Hope it helps!

[tivac]

@isidrok I wasn't able to repro this with the latest rollup and @modular-css/rollup versions.

https://gist.github.com/tivac/a07d38ada6f3119aa663da7760f822bb

Do you have some more details about your setup that might help illuminate the problem?

[isidrok]

Sorry, forgot to mention you must use hashing for the entrypoints:

output.entryFileNames: '[name].[hash].js'

Note that auto-extracted chunks come hashed by default.

[tivac]

Could you fork that gist and update it so you can repro? I've messed around with experimentalCodeSplitting, output.entryFileNames, and a few other options and still can't get anything like a reliable repro.

[isidrok]

Sure, will find some time later today.

Edit: here it is. The problem was I'm trying to use this module just to have css-files generated, but without using css-modules, thatś why I just use import './some.css without actually instantiating its styles. In this case there is no generated .js file and the hash changes.

[tivac]

Working on a potential fix using the source file name instead of the entry file name, it does have at least one unfortunate side-effect though. Getting deep into the weeds on regexps/stripping stuff from entry filenames seems real dangerous though so I prefer this as the least-worst option atm.

[isidrok]

Thanks! This part is specially interesting:

const name = outputOptions.file ? entry : contents[contents.length - 1];

Is it safe to assume that the last module is always the entry one?

Let me know if I can help with something btw.

[tivac]

I did some quick testing with multiple config-defined entry points as well as dynamic imports and the last element in the modules array was always the source file, based on some spelunking through rollup's code last night that assumption seems to hold true as far as I could tell. It feels a little bit like an internal implementation detail that shouldn't be depended on, so I don't love it as a solution.

The remaining issue is that dynamicly-generated chunks will have their .css file named after their original name, not their rollup-created name (chunk.js, chunk1.js, etc) which is weird. Not sure what I'm going to do about that.

[isidrok]

With dynamically-generated chunks you mean the ones that rollup generates to hold common dependencies, am I right?

That's definitely a tough one but I think that there's no way atm to get the chunk name if it doesn't match the file one without doing some weird regexp stuff. Having a name different from the one of the output.chunkFileNames resolved [name] would make the convention chunkName.js - chunkName.css unreliable.

Maybe let's wait and see how rollup/rollup#2549 evolves.

[tivac]

Not going to publish tonight but now that rollup@0.68 is out I should be able to get a fix for this rolling soon!

[tivac]

Fixed in @modular-css/rollup@18.0.0.