@mxmrtns since we are now including extensions, the logic will become more complex.
Example:
inside the semanic tokens, we reference to a core token value.
Now if we want to use SCSS based functions like:
lighten(myColor, 10%)
We can not use CSS variables as input (SCSS is not aware of their values).
To do it right, we need to parse all token files first and create a JS map of keys (namespaces) and values. This also needs to honor direct extensions of values.
Once we have the map in place, we can then parse each file on its own and in case a value references another token and has an extension (lighten(), darken(), etc.), then we can replace the token value with the plain value from the map.
Tokens without an extension can still get mapped directly to CSS variables.
@mxmrtns since we are now including extensions, the logic will become more complex.
Example:
inside the semanic tokens, we reference to a core token value.
Now if we want to use SCSS based functions like: lighten(myColor, 10%)
We can not use CSS variables as input (SCSS is not aware of their values).
To do it right, we need to parse all token files first and create a JS map of keys (namespaces) and values. This also needs to honor direct extensions of values.
Once we have the map in place, we can then parse each file on its own and in case a value references another token and has an extension (lighten(), darken(), etc.), then we can replace the token value with the plain value from the map.
Tokens without an extension can still get mapped directly to CSS variables.