[Bug]: CSS Class Name error.

[1yasa]

System Info

System:
OS: macOS 14.4
CPU: (32) x64 13th Gen Intel(R) Core(TM) i9-13900KF
Memory: 12.14 GB / 32.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 21.6.1 - /usr/local/bin/node
npm: 10.2.4 - /usr/local/bin/npm
pnpm: 9.0.4 - /usr/local/bin/pnpm
Watchman: 2024.04.22.00 - /usr/local/bin/watchman

Details

All css modules classname ignore file path info(deep directory), this will make styles chaos in app.

In addition to automated packaging testing, can rspack also incorporate some end-to-end (e2e) tests under different configurations to test the actual rendering effects.

Thereby preventing rendering issues that may arise after updating rspack (to avoid being unaware of obvious rendering problems, even though e2e tests cannot be conducted for unattended releases and do not confirm the correctness of rendering.

it is still better than having to issue a new release immediately after the previous one)?

Suggest use repack.dev as e2e test(test.rspack.dev) when rspack updates, guys you will know prod issue in production.

Reproduce link

No response

Reproduce Steps

above

[1yasa]

v0.6.4

[1yasa]

Same error when set module generator:

So where is [path]?

[1yasa]

Seem cause by https://github.com/web-infra-dev/rspack/pull/6444/files.

The testing ignore the deep dir cases.

[ahabhgk]

Thanks for report, we will release the fix in today

[chenjiahan]

Thanks, we will add more e2e cases for CSS Modules.

[daveskybet]

Hi @ahabhgk, quick question on this hotfix.

I'm the reporter of the hashing issue in #6435 Which fixed my issue of css module hashes not matching Webpack/MD4 hashes generated elsewhere which was released in 0.6.4.

I did wonder about the missing deep path info so this addition is welcome, however it seems to have reintroduced the issue I reported above, where the hashes don't seem to match.

Using the https://github.com/rspack-contrib/rspack-examples/tree/main/rspack/css-parser-generator-options example an MD4 hash for a deep path of ./legacy/index.css should be 2c15d43fe622e87bbf5d (length limited to 20), but the class name generated using [hash] in the example (with v0.6.5) results in d7377dc02a1f125c4876

Is this a regression on the previous fix, or am i missing something?

Thanks

[ahabhgk]

Webpack experiments css should have the same issue about the deep path info, so the hash result of rspack is actually correct, we will submit a fix to webpack soon

[daveskybet]

Correct @ahabhgk, Webpack also has the same issue with deep path which needs to be addressed, however my issue is unless there's something else going on in the hashing logic, the hash isn't a straightforward MD4/Hex hash of the deep path value, as the path in the example of ./legacy/index.css generates a different hash (with the default output.hashFunction and output.hashDigest values) than you get either using an MD4 generator (such as https://en.toolpage.org/tool/md4) or something like Webpack's loader-utils getHashDigest("./legacy/index.css", "md4", "hex", 20)

[ahabhgk]

We will take a look, but just curious, what's your use case which needs to have the same hash result of the className

[daveskybet]

Thanks @ahabhgk, our use case as mentioned in #6435 is the need to generate mapping json files of the classes which in our existing Webpack solution uses postcss & postcss-modules to generate these files, but moving to Rspack the hashes don't match (although they briefly did with the changes made for 0.6.4, but then broke again in 0.6.5).

If there's an alternative method you can think of to output these mappings then i'd be happy to hear it.