[contenthash] for localIdentName

[Netail]

Feature Proposal

Expose [contenthash] string template for localIdentName

Feature Use Case

Note

Actual issue found with rslib, an upstream of rspack, that tries to equal webpack.

We have a design system built using typescript & sass, which we in the cicd transpile/compile to javascript & CSS. We already handle CSS modules on this end, so it adds a hash at the end of the classes. This hash is the same each build, even when some lines changed.

The problem lies in our monorepo with packages & micro-frontends. Some packages use the design-system & the apps themself, where the version of the design system can differ between each. When an app gets bundled the same class could end up in the bundle twice, if a package uses a certain component & the app. If some lines get changed between versions and both versions are bundled together, you'll get clashes on the classname.

So, it would be nice to someone differentiate these 2 based on if the content has changed within the design-system so classes don't clash. And resulting in the same class hash if no changes have been made between versions.

Please paste the results of npx webpack-cli info here, and mention other relevant information.

Not needed

[Netail]

Would be nice to even generate this hash based on the class content instead of the full file, but I think that's a bit excessive

[alexander-akait]

Would be nice to even generate this hash based on the class content instead of the full file, but I think that's a bit excessive

We already doing it

https://github.com/webpack-contrib/css-loader/blob/master/src/utils.js#L321

So I don't what we should change

If you want to have two different classes you can use ${prefix}-[contenthash], where prefix is name of your package for example

[Netail]

We already doing it

Mhm let be get back to you on that one then.

The supported template strings on https://webpack.js.org/loaders/css-loader/ don't mention [contenthash] and suggest it only uses the file-name path + the class name, not the style attributes int he class itself

[alexander-akait]

@Netail Sorry I don't understand what you try to achieve - do you want to have different classes or the same?

[Netail]

@Netail Sorry I don't understand what you try to achieve - do you want to have different classes or the same?

The [hash] template literal is the same each build, even if a line in the file got changed, right?

So let's say

// src/component.css
.header {
    color: blue;
}

changed to

// src/component.css
.header {
    color: red;
}

It will result in the same hash as the hash is generated based on the class name + file path. (Which both didn't change)

Would be nice to expose a hash template literal that's generated based on the file content, like the [contenthash] for chunk files

[alexander-akait]

hash for locals - no, any hash things are using locals to calculate locals, it is not file based

Would be nice to expose a hash template literal that's generated based on the file content, like the [contenthash] for chunk files

You can use [contenthash] here - https://github.com/webpack-contrib/mini-css-extract-plugin?tab=readme-ov-file#chunkFilename

it is not related to css-loader

localIdentName is only about local generation and don't related to hashes of file

[Netail]

localIdentName is only about local generation and don't related to hashes of file

Yeah, that's currently not a feature. But would like to request this feature if possible.

Which comes in handy when using multiple versions of a design system package are used within a app, to prevent conflicts in styling due to classes having the exact same name.

Let's say version 1.0 has the following class:

.heading-W6TaY {
    color: red;
}

And version 2.0 has

.heading-W6TaY {
    color: blue;
}

(Both the same hash, as the class name nor file path changed on the design-system side, where the hashes are calculated)

And both end up in the app's bundle, it will result in a "conflict" and will the browser use the last one defined.

[evenstensberg]

This will be very bad performance wise. Significantly higher build times etc..

[Netail]

This will be very bad performance wise. Significantly higher build times etc..

Because css-loader has to calculate the contenthash? Can't the webpack core provide it somewhere, as it already calculates one?

[evenstensberg]

Best case we can check if an node is changed from the previous, worst case we need to store the entire value, previously and current of a node when parsing.