Ability to use a tokens file as source that gets omitted in the output
I was wondering if it's in the scope of this project to provide a way to use a core-tokens.json file for example as a means to resolve tokens in the input file, but without those core tokens being outputted.
As an example:
/// core json
{
"Color": {
"core": {
"white": {
"$type": "color",
"$value": "rgb(255, 255, 255)",
"$description": "",
"$extensions": {
"mode": {},
"figma": {
"variableId": "VariableID:4824:10279",
"collection": {
"id": "VariableCollectionId:4824:10278",
"name": "Color",
"defaultModeId": "4824:0"
}
}
}
}
}
}
}
/// input json
{
"primary": {
"$type": "color",
"$value": "{Color.core.white}",
"$description": "",
"$extensions": {
"mode": {
"Light": "{Color.core.white}",
"Dark": "{Color.core.black}"
},
"figma": {
"variableId": "VariableID:1340:1704",
"collection": {
"id": "VariableCollectionId:91:10",
"name": "Color",
"defaultModeId": "91:4"
}
}
}
}
}
And the expectation is to get an output of just:
:root {
--primary: rgb(255, 255, 255);
}
With the core tokens omitted but only used to resolve the input token.
Or even add the core source file as a separate output that gets imported into the main output like:
@import 'core.css';
:root {
--primary: var(--ds-color-core-white);
}
And the expectation is to get an output of just:
:root { --primary: rgb(255, 255, 255); }
Thanks for raising! The tricky bit here is setting a boundary around knowing what to resolve vs not. As soon as you start using modes, and start chaining aliases together, it usually increases the chance that final value is resolved incorrectly.
Today, you can use the transform() option of the CSS plugin to, say, resolve that primary color as you’d like. But we don’t have a way to omit tokens from the output right now (but that’s been requested and is on the roadmap!).
Using the transform() API may seem a little finicky, but it exists to do these sorts of things. Because you may have one usecase, but others very likely would have the same request, only the tokens would be located in the same file, or be named a certain way, etc. etc. And since there’s not an existing concept in the DTCG specification that describes something like this, this is usually in the realm of “applies to certain design systems but not others” which is why the transform() API was created.
Closing as I don’t think we’ll be able to support this. It’s worth noting that there’s a config.ignore setting to completely ignore tokens from output. But in the case of some source tokens being used as aliases for other tokens, we do want to preserve all those in the final output otherwise the tokens may be the incorrect value.
I’ve also been doing some work on the upcoming Resolver Spec to DTCG, which is likely to be a good, officially-supported upgrade to modes. And in those instances, the resolutions can be even more complex! And even more likely that trying to remove tokens from output could mean incorrect output.