RFC: What would you like to see in Style Dictionary 4.0?👩🏽‍💻💡

[chazzmoney]

Hey SD community... we need your help!

We would really love to hear what YOU would like to see in SD 4.0. Answers to this might include answers to these questions:

• What do I wish I could do with SD that I just can't right now?
• What do I want from a next generation Design Token Management tool?
• Whats next after Style Dictionary?
• (Your idea here)

We would love to hear all your thoughts - we might* even send you some SD swag***...

• There is no guarantee, I don't even know how to send something physically to someone on github...
  *** Right now this ONLY consists of stickers of our mascot, Pascal. But I really want a Pascal stuffie/plushie... and maybe a tote bag, or a water bottle, or coffee cup, or phone case, hoodie, throw pillow, pajamas, or... really, anything Pascal. Danny made him way too cute to be relegated to an existence consisting only of stickers.

[bherbst]

I'd love to see a few things to better support strongly typed languages such as Kotlin/Java:

• Support passing context between a transform and a format. Kotlin, Java, Swift, etc. require imports, but when a transform such as color/composeColor uses a type that needs to be imported, there's no way to tell the format that it needs to add that import statement at the top of the file- we just have to import all the things a transform could want.

• References across output files. For example, I'd like to be able to have Style Dictionary support generating these two objects in separate files in a safe manner:

  object Palette {
    val gray: Color = Color(0xcccccc) 
  }
  
  object LightColors {
    val background: Color = Palette.gray
  }

  Right now I'm doing this by passing Palette as a className option to the format that generates the LightColors, but that feel hacky- I'd love if references could keep some of that context for me.

[lewishealey]

I'd love to be able to create different formats and transforms based off different sources (if we can't do already)

[dbanksdesign]

@lewishealey could you elaborate a bit on this?

[chazzmoney]

@didoo @nhoizey @EvanLovely @kharrop @Tenga @jbarreiros @tonyjwalt @7studio @lukasoppermann

Would love your thoughts!

[lukasoppermann]

I am not sure how easy it is now, but splitting output by theme would be interesting.

E.g. you have dark / colors / background and light / colors / background and want to get two css files or better be able to define if two files or maybe one file but nested within two parents: body {...} and body.dark-mode { ... }

Still very rough, but this is something we work on currently. (Not just for the web of course)

[didoo]

Some initial thoughts.

I think a possible focus could be on making SD do things better, not necessarily do more. For example, I think one inevitable thing (and I am not saying it lightly, I understand the complexity of it) would be to convert the entire codebase to TypeScript. I know it's a huge, massive work. But this would make the refactoring of code (for its evolution) so much better! For those who have to touch the codebase, the knowledge that there is something in place that allows code refactoring without worrying that you forgot to change one prop or variable name somewhere in a file, is a game changer. This will not impact the final user, I know, but I think is a very important "safety feature" to add to the project.

Another thing I was thinking was the website and the documentation: I know also this one is huge and requires a massive effort, but I think is long past overdue :) (I suspect there is also a GH issue, somewhere, where this discussion already happened). There are so many things we could do in this area, and so many good websites of open-source projects where we could get inspiration from (in terms of exposing to the users the documentation/information in a smart way)

One last thing, possibly controversial: what if instead of "adding something" we "remove something"? The risk I see for many open-source projects is feature bloat, and I would be extremely sad to see this happen to SD.
Quoting Antoine de Saint-Exupery “Perfection is Achieved Not When There Is Nothing More to Add, But When There Is Nothing Left to Take Away” 😀

[jacoblapworth]

Support for naming structures with nested/default values.

Given end result token names of:
$color-white
$color-white-alpha

It's not currently possible to achieve this with a token structure like:

  color: {
    white: {
      value: '#fff',
      alpha: {
        value: 'rgba(1,1,1,0.8)',
      },
    },
  }

The alpha token is treated as an attribute of the white token.

We're currently solving this with a default value, which is then renamed in the formatter to remove the suffix. Not an ideal solution as we should only be mutating tokens during the transform step.

  color: {
    white: {
      default: {
        value: "#fff",
      },
      alpha: {
        value: 'rgba(1,1,1,0.8)',
      },
    },
  }

Possible solutions

• A new type of transformer for modifying paths. This could allow us to rearrange the structure dependent on platform/token matcher.
• Provide a configuration to limit the keys of attributes, in order for the parser to understand when to continue traversing the object for values.
  • this could also be achieved by enabling users to provide a custom traverser

[isaachorton]

I would like the ability to create multi-file formats. For instance, being able to generate an iOS Asset Catalog containing named colors (*.colorset)

Asset Catalog Ref

[nhoizey]

Hi, there are multiple things I would like to have in SD, which are already listed in the issues.

I agree with what @jacoblapworth asks for, and it is already in #366.

For Sass modules with @use, I would like to have a simple way to generate simple Sass files with automatic addition of @use directives where required, depending on references: #618

As Design Tokens are often part of a Design System, I would like to have a simple way to document tokens. I'm currently struggling with Storybook to do that, as I showed in #477 and storybookjs/storybook#7671 (comment) . Maybe there could be a Storybook plugin as part of the SD project. Maybe for other Design System / documentation tools too.

I would also like to be able to "treat file path as prefix for property path", as asked in #104

[bhdicaire]

I would appreciate the ability to transform design tokens into color palettes usable by designers such as .ase, .clr and .sketchpallete.

You can refer to to the following project to estimate the required effort:

• https://github.com/IBM-Design/color-bee <-- Color Bee takes one JavaScript file of colors and creates .ase, .clr, .json, .scss, and .sketchpallete files
• https://github.com/kitoko552/clrpalette <-- Generate a .clr from a JSON file

There is also mac centric projects (e.g., objective-c and swift):

• https://github.com/ramonpoca/ColorTools
• https://github.com/tomokitakahashi/ColorPalletGen
• https://github.com/kaelig/tokens2palettes-example
• https://github.com/muukii/ColorGen
• https://github.com/naoty/clr
• https://github.com/RedMadRobot/RMRColorTools-iOS

[uptonking]

I want more built-in support for integrations/plugins/extensions to popular design tools like figma, sketch, framer-motion...

[nhoizey]

Now that there is an official glossary published by the Design Tokens W3C Community Group:
https://www.designtokens.org/glossary/

Just as "properties" were renamed to "tokens" for v3, v4 could see "category" (in CTI) renamed to "type", but then "type" would have to be renamed to something else… maybe "property"? 😅

We would move from CTI to TPI…

[andre-brdoch]

I would love to see the possibility to derive different tokens from the same source! For example color-red would lead to color-red (hex) and color-red-rgb (rgb). color-red-rgb can then be referenced by other tokens, like any other token can.

Right now we have to use formats, which makes referencing the derived rgb-tokens difficult. To us, the rgb-tokens are first-level tokens. We simply dont want to specify them additionally to the hex-tokens, since that is redundant.

[lukasoppermann]

While I have different use cases, I also would love something like @andre-brdoch see: #695