Style-dictionary: Feat: Alias Fallbacks

[ryanfitzer]

Looked through the docs, examples, and issues, but not seeing any feature for defining fallback values when aliases do not resolve. For example, in a multi-brand system, I would like to have global defaults for all possible brand tokens. Then a particular brand could override just the tokens needed.

Global:

{
  "color": {
    "error": {
      "value": "{color.brand.error.value || 'red'}"
    },
    "success": {
      "value": "{color.brand.error.success || 'green'}"
    }
  }
}

Brand One:

{
  "color": {
    "brand": {
      "success": {
        "value": "blue"
      }
    }
  }
}

This would alleviate the need for each brand to define all tokens, and instead define just the overrides. The syntax could also use a reserved key name like default (or DEFAULT, or VALUE) instead of an expression:

Global:

{
  "color": {
    "error": {
      "value": "{color.brand.error.value}",
      "default": "red"
    },
    "success": {
      "value": "{color.brand.error.success}",
      "default": "green"
    }
  }
}

[nhoizey]

@ryanfitzer wouldn't it be easier the other way?

Here, it looks like your global tokens are inheriting the brand ones, meaning you have to write all values with fallback/default.

What about a default set of tokens, and the brand one only overrides some values?

default:

{
  "color": {
    "error": {
      "value": "red"
    },
    "success": {
      "value": "green"
    }
  }
}

Brand one:

{
  "inherits": "default",
  "color": {
    "success": {
      "value": "blue"
    }
  }
}

[ryanfitzer]

@nhoizey Are you proposing this as a better API, or did I miss the docs for "inherits": "default"?

Your idea makes a lot of sense. Unless I'm missing some API flexibility mine has over yours, I would think yours would be a better option.

I could also see this being an option in the config, instead.

[nhoizey]

@ryanfitzer this is a suggestion for a new idea, sorry if this wasn't clear… 😅

[chazzmoney]

Great question. I think that this can be done using the config.include parameter for your global (default) styles and the config.source parameter for your brand (overwrite) styles.

https://amzn.github.io/style-dictionary/#/config

Let me know if this helps, or if it doesn't fit your use case.

[dbanksdesign]

I wrote up a quick example as well that hopefully helps...

https://github.com/dbanksdesign/style-dictionary-multi-brand-with-defaults

[ryanfitzer]

@dbanksdesign This is great! Thanks so much for putting this together. I'm going to reconcile this with the mental model I've been working with and post back with any feedback.

[ryanfitzer]

@chazzmoney This makes total sense and I feel a bit embarrassed that I overlooked/misunderstood the include option before creating this issue.

@dbanksdesign Your example repo was really helpful in understanding how to organize defaults using the include option.

And after working for the past 2 months with this approach on a large, multi-brand project, I can definitely say it has worked well for what I needed.

For those that are interested: https://github.com/Tapestry-Inc/design-tokens. Any and all feedback is welcomed.

Here's are the token listing pages that get generated for each brand:

• Coach: https://assets.tapestry.com/ux/design-tokens/1.0.0/coach/index.html?v=1
• Stuart Weitzman: https://assets.tapestry.com/ux/design-tokens/1.0.0/stuart-weitzman/index.html?v=1