-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable granular CSS variables output #212
Comments
If the spec supported a $deprecated property would that be sufficient? |
Or, alternatively, if you read that issue some people have more advanced requirements of organizing their tokens, and they may have additional designations other than “deprecated.” What if we allowed you to specify deprecation based on a token property, e.g.?: /** @type {import('@cobalt-ui/core').Config} */
export default {
tokens: './tokens.yaml',
ignoreToken: (token) => token.$extensions.deprecated || token.$extensions.status === 'deprecated',
}; The |
$deprecated could be interpreted so that the value is not valid which is not the case. $extensions could be used for this as this is a tool-related issue. To further add details to the current state, this is possible by using transform but is somewhat hacky. transform: (token) => {
if (token.id.includes('typography.content') || token.id.includes('typography.heading')) {
return true;
}
}, |
Good point. I guess that just leaves 2 questions:
Perhaps the answer is “sometimes both” and we could add a global ignore option for the core, and also add some way to remove outputs from individual transform: (token, options) => {
if (token.id.includes('id-i-do-not-want')) {
return options.delete;
}
} Note: the way transform works, if you return
And yes just an additional slightly-off-topic thought: yes the original design of |
Update: the latest version of Terrazzo supports this! There’s an ignore option where you can either specify globs of tokens to ignore, and/or respect the |
Please enable configuring what tokens to exclude from the output. This would simply make generating CSS variables a lot more flexible and allow optimizing for specific use cases where a token or a token group is not needed. Below is a suggestion how this might work in practice. Adding
ignorePatterns
into the config would allow setting what tokens or groups to exclude from output.Currently the only option is to use modes which are intended for a different use case and would result in a lot of unconvenience.
The text was updated successfully, but these errors were encountered: