Support for token(...) in CSS with strictTokens enabled

[etlovett]

Description

In my project, I want engineers to use the token(tokenNamespace.value) format (e.g. token(blue.50)) for all Panda token references, so that token usage looks like CSS variable usage (var(--namespace-value)) rather than built-in value usage (e.g. blue or mediumseagreen) to make it very explicit to future readers of the code when we're using Panda tokens.

Unfortunately, enabling strictTokens means that Panda generates TypeScript types that require using only the the bare tokenNamespace.value format (e.g. blue.50), not the token(...) format.

Could we change the way that Panda generates TypeScript types to either support both formats or have a config option that specifies which format we want to support (akin to how the syntax config option allows us to constrain how we can write styles)? My preference would be the latter, since then it would allow me to specifically disallow the "bare" non-token(...) format.

Problem Statement/Justification

When managing a codebase that has lots of contributing engineers and which we expect to be long-lived, constraining people to use only valid values of the format token(...) helps ensure consistency and therefore maintainability across the codebase. It would therefore be helpful to be able to use strictTokens and the token(...) format together.

Proposed Solution or API

Supporting just the token(...) format requires changing this line of code in the generator package to the following:

      const finalTokens = Array.from(value.keys()).map((v) => `token(${key}.${v})`)
      set.add(`export type ${typeName}Token = ${unionType(finalTokens)}`)

Obviously landing that simple swap would break anyone who does not want to use the token(...) format. I assume this would be undesirable, so I would propose that either we allow both the current and token(...)-wrapped versions, or we support a config option that lets us pick between them. My preference would be the latter so that I can limit the number of patterns in my team's codebase.

Alternatives

The obvious alternative is to either not use strictTokens or to stop using the token(...) format, but I think both of these choices would make my codebase less maintainable over time.

Additional Information

Implementing the "either" version should be easy, and I'd be happy to take a stab at implementing the config option version as well, if you'd be open to this change!

[segunadebayo]

That’s an interesting idea 💡

I reckon that you could create a codegen plugin for this in your project and modify the generated token.d.ts code.

Here are some plugin code you could get ideas from:
https://github.com/astahmer/pandabox/tree/main/packages/panda-plugins/src