

Source code:

Output:

Cache file in .cache:

I think that the repeat hash is the key that caused this problem. What's we expected is, compile .Xxx {} to .Xxx_hash , and so in js we could use import styles from './Xxx.css';, the value of styles should looks like {".Xxx": ".Xxx_hash"}.
But, we got .Xxx_hash_hash, and the value of styles is like {".Xxx_hash": ".Xxx_hash_hash"} , so all className set by styles.Xxx is undefined.
The codes I use has already push to here . You can take a try with it.
parcel builtin server or Phx.server .css file, change and save it to trigger the parcel watch process reload the code,.same bug here
Same bug here, anyone know if there is a fix on the horizon? I'm trying to look into the source code but I'm not familiar enough with it and there's not enough comments to easily follow it.
It's pretty obvious that the bug is being caused by feeding the resulting stylesheet back through the transform, generating a new stylesheet with double-hashed classnames, and a new JS object with the single-hashed property names.
Making subsequent changes to the file can cause this bug to happen again multiple times, increasing how many times the hash is applied to the classnames. However it doesn't always happen, it seems to go in a pattern (sometimes every 2nd change triggers it, sometimes every 4th change).
For example if I add and remove a class from the css file, the number of hashes on each classname increases regularly every 4th transform: 1,2,1,2, 2,3,2,3, 3,4,3,4 etc
If, for example I re-save the file without any changes, it does the same: 1,2,3,2, 2,3,4,3, 3,4,5,4 etc
Here's the thing that's really confusing me. I have caching disabled (verified by the non-existence of the .cache folder), so it's not an issue with the cache. BUT restarting the dev server does not always fix the issue. For example I just re-started the dev server 3 times and got 2 instances of double-hashed classnames, and one instance of (proper) single-hashed.
That would be fine if it was random, but it's not. Once I get a single-hashed file, no amount of re-starting the dev server will ever get me back to double-hashed.
This means that some state is being saved somewhere other than in the cache. If caching is not being utilised, shouldn't builds be consistent and idempotent? At the moment they are not.
I've just noticed the same, in my case, it was the moment I've added PostCSS configuration. I guess it could be related to this directly, since removing the .postcssrc file did solve the issue.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs.
Most helpful comment
Same bug here, anyone know if there is a fix on the horizon? I'm trying to look into the source code but I'm not familiar enough with it and there's not enough comments to easily follow it.
It's pretty obvious that the bug is being caused by feeding the resulting stylesheet back through the transform, generating a new stylesheet with double-hashed classnames, and a new JS object with the single-hashed property names.
Making subsequent changes to the file can cause this bug to happen again multiple times, increasing how many times the hash is applied to the classnames. However it doesn't always happen, it seems to go in a pattern (sometimes every 2nd change triggers it, sometimes every 4th change).
For example if I add and remove a class from the css file, the number of hashes on each classname increases regularly every 4th transform:
1,2,1,2, 2,3,2,3, 3,4,3,4 etcIf, for example I re-save the file without any changes, it does the same:
1,2,3,2, 2,3,4,3, 3,4,5,4 etcHere's the thing that's really confusing me. I have caching disabled (verified by the non-existence of the .cache folder), so it's not an issue with the cache. BUT restarting the dev server does not always fix the issue. For example I just re-started the dev server 3 times and got 2 instances of double-hashed classnames, and one instance of (proper) single-hashed.
That would be fine if it was random, but it's not. Once I get a single-hashed file, no amount of re-starting the dev server will ever get me back to double-hashed.
This means that some state is being saved somewhere other than in the cache. If caching is not being utilised, shouldn't builds be consistent and idempotent? At the moment they are not.