The hash of css class names packaged on different platform systems is inconsistent

[J-env]

What version of astro are you using?

1.5.2

Are you using an SSR adapter? If so, which one?

None

What package manager are you using?

npm

What operating system are you using?

Mac

Describe the Bug

The hash of the css class name is inconsistent, resulting in a change in the hash of the packaged file.

// example.astro
<style>
.example { 
  font-size: 34px;
}
</style>

Mac output file: [name].f6446fc8.css

.example:where(.astro-6YSHC6AL){font-size:34px}

Windows output: [name].12333479.css

.example:where(.astro-CVKMEFR4){font-size:34px}

Link to Minimal Reproducible Example

none

Participation

• I am willing to submit a pull request for this issue.

[bluwy]

Looks like the Astro compiler builds the hash based on the content and file name since withastro/compiler#513. Maybe we should use a project-root-relative path to compute the hash? cc @matthewp

[J-env]

@bluwy

import path from 'node:path';
import slash from 'slash';

// project root
const root = __dirname
// current filepath
const src = ''

const slashSrc = slash(path.normalize(path.relative(root, src)));

const hash = createHash(slashSrc)
// const hash = createHash(slashSrc + `${code}`)

[matthewp]

Yes we should! I plan on fixing this. @J-env this happens inside of our (Go-based) compiler. But I think we have all of the information to make this root-relative.

[matthewp]

Looking into it, we don't actually pass in the moduleId so it is just based on the source. I wonder if the source is what is different between platforms, probably because of the different line endings?

[malcolm-kee]

In my case this issue seems to be causing certain CSS modules rules works in dev but missing in prod.

• in JS: _element_17ddh_2
• in CSS: _element_d3dod_1

I'll try roll back few Astro versions to see when it starts breaking.

Update: I can confirm that for my case, [email protected] is the version that introduces the regression. It was fine before that.

Update 2: I tried to create a minimal reproduction but not able to. Wish I can be more helpful :(

[bluwy]

I think this is already fixed but forgot to closed. We are now deriving a root-relative normalized path to generate the hash, so something like /src/pages/index.astro. I'll close this for now.

@malcolm-kee if you can reproduce this, feel free to open a new issue. Thanks!