[FEATURE REQUEST] Support sets of token JSON files
freemansoft opened this issue Β· comments
π¬ Support a directory of JSON files
It looks like the program supports a single JSON input file. The design tokens are designed to support core and context tokens in different files
β Link to specification or documentation (if available)
(Design Tokens - Material Deisgn)[https://m3.material.io/foundations/design-tokens/how-to-read-tokens] refers to a hierarchy of tokens. Typically these are in separate files.
- System Token,
- Reference Token,
- Default Value
I've done this in the past by merging the token files into a single dictionary in the order specified by the metadata files.
Looking at example/bin/example-themes.json
the top-level sections in that file are sections that can be their own file when you have a multi-file design token file set. The $themes and $metadata sections don't include pathing info because everything is in the same location single file
Sections
- core
- light
- dark
- theme
- $themes
- $metadata
In a single json file. Every ref is basically to a top level item.
"$themes": [
{
"id": "33f7ab9c99363ec90d03707ec9b383c1259aadbe",
"name": "light",
"selectedTokenSets": {
"core": "source",
"light": "enabled",
"theme": "enabled"
},
"$figmaStyleReferences": {}
},
In a multi-file json definition, the references in $themes and $metadata must include pathing information
[
{
"id": "7347fd90e502aaece9e7cf40f79f188b93485a2a",
"name": "default - light",
"selectedTokenSets": {
"global": "enabled",
"theme/light": "enabled",
"theme/dark": "disabled"
I can do a PR to support separate sections (light, dart, etc) if you give me an idea of how you want this to look.
- The code could convert the individual files into a single map by loading them in the order in $metadata. The
$metadata
section can be modified to remove the pathing. The $themes section could be modified to remove the pathing - Other?
Candidate is PR #4