Permit custom identifier hashing

[FrancoisChabot]

Simple custom identifier hashing. Not quite the exact same feature request, but related: #313

This may not be the best possible API for this, but it has the benefit of being a backwards-compatible drop-in for any adapter/plugin that already exposes IdentifierOption directly.

For example, with the vite plugin, one can do:

plugins: [vanillaExtractPlugin({
      identifiers: (scope, index) => { return 'insert_logic_here'; }
    })],

[changeset-bot]

🦋 Changeset detected

Latest commit: de0f4e7

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 8 packages

Name	Type
@vanilla-extract/css	Minor
@fixtures/features	Patch
@fixtures/low-level	Patch
@fixtures/recipes	Patch
@fixtures/sprinkles	Patch
@fixtures/themed	Patch
@fixtures/unused-modules	Patch
vanilla-extract-example-webpack-react	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[mattcompiles]

Hi 👋

What is the scenario in which we would suggest utilising this feature? I'm not completely against adding it, but I don't want to add features just because we can. In the past when this was suggested our team normally felt that other options would be a better solution to the problem.

[douglaseggleton]

Might be a relevant use-case - we use storyshots and the ability to have a consistent readable debug instead of hashes would be helpful.

[FrancoisChabot]

This could be used to improve page compression by creating shorter identifiers via perfect hashing.

[plesiecki]

I suppose with that feature I would be able to migrate CSS Modules (with custom hashing fn) codebase to vanilla-extract 🤔

[CroModder]

This one is a must have for us. The use case is that there are multiple parts on the page (micro frontends) that are using different versions of the shared lib that's using vanilla extract as a styling solution. And when multiple versions are being run simultaneously, it happens that classname hashes are not unique. In our old lib we used CSS modules and appended library version on the generated hash which assured us from hash clashes, but it is also very helpful when debugging...

[dan-harris]

I'd also like to add a usecase for this PR - generating some stable classnames as part of a Design System implementation.

Currently exploring an exact approach, but would love to use vanilla extract for a range of usecases across 'ts-focussed' components, along with produce some 'template-focussed' utility css / shared classes. Having control of identifiers would give us the choice as to how we implement and where we buy in on the safety of the generated classnames.

[roginfarrer]

Hello! I'd also voice support for this. My company is in an unfortunate circumstance where two different versions of the design system can be bundled onto a page, and we don't have much control of it. We're running into cases where the same classes have different styles, resulting in style collisions. We'd like to use this feature to make sure that each bundle produces a truly unique class across bundles.

[mwood23]

+1 for this one. We embed widgets onto websites and need to add a unique identifier to ensure there will never be clashes on classnames since we don't own the environment.

[juniorconquista]

Hi 👋 @graup
Do we have any news about this feature? He very helpful!

[PatrickMennen]

@mattcompiles in issue #841 you mention that this goes against the philosophy of a solution like vanilla-extract.

Does this mean this feature is not being considered whatsoever? This discussion illustrates that developers have a need to disable (or customize) the scoping of the output class names manually.

Could we at least get an official response on this?

[altrim]

Hi,

Any new updates on this one?
We have a similar use case where we have a micro frontend solution and multiple views are using different versions of the shared library that is built with vanilla extract.
Having the option to customise the identifier would allow us to generate different styling based on the lib version to avoid clashes.

[bjgrosse]

I would really like to generate atomic class names with a hash of the selector+property name, etc. This is for deduplicating CSS atomic classes so that the last one applied takes effect.

[PatrickMennen]

just bumping this one ;-)

[otaviomad]

This PR itself needs some updating. The merge conflicts, but that's easily fixable.
Also, a check for typeof identOption === "function" in line 25 and 57 for transform.ts in the integration package is necessary for getting the debugIds.

[mihkeleidast]

One other usage here: we'd like to keep className hashing as is, but disable the variable name hashing completely. We support using the variables in both regular CSS and vanilla extract, which means we need to provide and apply both the non-hashed variables and vanilla-extract variables (essentially duplicated code). Since we support regular CSS and using non-hashed variables there, we don't care much about scoping vanilla extract variables either, they are global anyway,.

[greenskybluephish]

@mattcompiles Any chance you could outline or link to what those better alternatives would be? Similar to some commenters above, I'm on the cusp of releasing an internal component library, which will be used in a micro-frontend architecture. During our beta, we've hit issues with apps having differing versions of our package installed, as class names are the same but their properties can be different.

With just the ability to add an additional versioning string to the class names, I believe we would eliminate the problem altogether, but as it stands we are looking at much less desirable alternatives, like needing to scope our CSS under version classes, i.e.

.v2-0-0 {
import '@component-lib/styles.css'
}

[wesgro]

This would be an incredible addition for Design System authors that have very little control over where and what version of their css ends up on any given page.

[jdecastroc]

@mattcompiles is there any update in regards this PR?

This still being a mandatory requirement to have vanilla-extract working properly in the scenario where several microfrontends using internally vanilla-extract, are renderer in the same page. The hash-clash is happening right now making the need to have custom hashes real.

Would love to see how this could progress or what is needed to be done :D

[mattcompiles]

CLosing in favour of #1160