lukasoppermann/design-tokens

Feature request: Support of variables

Opened this issue · 22 comments

Hey there! As you probably know, Figma introduced variables. Will the plugin support the export of these variables in the near future?

Hey, there are many plugins that export tokens already. Figma even has a sample plugin that exports tokens: https://github.com/figma/plugin-samples/tree/master/variables-import-export

I don't really see what value the plugin could bring over those other plugins.

@lukasoppermann I actually like the plugin you wrote best. Simple, fast. Very modifiable. I'd add a feature or two (and push up as a PR for such things), but it's my go-to solution, and I prefer small apps I can string together to make the big thing I want to have.

QUESTION: Do you see any inherent value in the addition of Variables in Figma or supporting them for export of tokens? I'm not finding the value add particularly obvious at the moment.

I would like to see it too. As of right now, it's the most comprehensive solution, where I can export Font-Styles, and Color-Styles, all at the same time, and convert in Style Dictionary in a single file.

+1, @StephanLoewe ! It would be convenient to have all exports in one click. Also, the sample plugin by Figma only works with the Enterprise Plan, as far as I know.

Hey, I am investigating it. I do understand the benefit of getting variables exported in the same manner as the other tokens.

This feature will only be added to the w3c export though. For anybody who is not on w3c tokens yet, this package I am also working on may help: https://github.com/lukasoppermann/style-dictionary-utils

That's great news! I think building the feature only on the w3c export is fair enough. I was wondering why Style Dictionary still doesn't support it yet. Didn't realize you build "style-dictionary-utils". Will definetly try it out to implement in the build process.

Hey folks, so the beta for variables is out. Please let me know if it works for you.

Note it only works in w3c standard tokens

Hey @lukasoppermann. I have created an internal plugin for a a rather big project that has an extensive variables setup with Figma already. Derived variables / ALIAS namings etc. that has to be distributed out to different Github repositories with the click of a button. I gladly show you how it works if it can provide any value towards your quest of supporting variables.

...And by the way: looking at your PR (#249) it surely looks like we went for the same approach 🥇.

Hey @marcuzgabriel,

thanks, but the PR you point to is already the implementation.

The complex part is not the variables itself, but adding it into a complex plugin like this was. But since it is done now, it should be all fine.

Hi, great work it really inspired me to dive a bit into style-drirectory. I tried it on my project and it didn't produce entirely valid output. In Figma, I have two collections primitives and tokens.

image

I don't know much about style-dictionary. However, as you see in tokens it tries to reference {Primitives.Primary/04} but in primitives the letter case is different. I also tried to run this json:

➜  style_dictionary style-dictionary build

flutter

Property Reference Errors:
Reference doesn't exist: tokens.light.bg.pressed.value tries to reference Primitives.Primary/04, which is not defined
Reference doesn't exist: tokens.light.bg.primary.value tries to reference Primitives.Primary/05, which is not defined

So I'm guessing there is something off.

exhtml commented

Hi folks! Same problem than @MikolajKakol over here. I was testing the plugin exporting only Figma Variables and seems that something doesn't get properly transformed between Variable Collection names. In my case I have my collections like these and they get exported as shown in the image:

image

As I've said I'm only exporting Figma Variables:

image

I've tried different configurations of settings with no luck:

image

Thank you very much for your work!

exhtml commented

Hi! following from the previous post, I've fixed the references to the correct collection names/nesting and executed the transformation. What I've seen is that Primitive Collection values get transformed propertly (as tokens are of "type": "color", but the Semantic Collection ones don't get transformed and are missing, as they are of "type": "alias" in the JSON.

If I change the type to "color" they get properly transformed, but they get the computed value:

--primitive-color-mode-1-colors-red-600: rgb(218, 41,28);
--semantic-color-light-brand-tiba-red-tr-600: rgb(218, 41,28);

wouldn't be nice if the references could be kept? like this:

--primitive-color-mode-1-colors-red-600: rgb(218, 41,28);
--semantic-color-light-brand-tiba-red-tr-600: var(--primitive-color-mode-1-colors-red-600);

:)

exhtml commented

Another thing I've seen is that variables of type "size" doesn't get converted unless you add this type to the StyleDictionary.registerFilter in transformTokens.js. It should be included I guess.

Edit: I see that in reality what should be fixed is that sizing variables should be exported as "type": "dimension", that is the correct syntax already included in StyleDictionary.registerFilter

Okay, here are some updates: https://github.com/lukasoppermann/design-tokens/releases/tag/v6.8.4

Please let me know how this is working for you.

exhtml commented

Hi Lukas! Thanks for your answer and the updates. I've tested it (only exporting 'Figma Variables') but the plugin freezes when clicking on 'Save & Export'. It throws an error in the console:
Cannot read properties of undefined (reading 'value').
Let me know if I can help providing more information.

Thank you very much for your time!

Hello! I believe I have a solution for 'Cannot read properties of undefined (reading 'value') issue.

Screenshot 2023-08-03 at 8 00 15 AM

Simply check if the value is a string (not an object). If true, then it's a variable.

I think we'd be safe to drop 'Mode 1' from the path via export. If the length of Variable collection modes === 1, no need to include 'Mode 1' (or whatever it is named) in the path. Else, we need it to point to dark/light/contrast modes. Besides, StyleDictionary wouldn't be able to naturally link if we did not drop 'Mode 1' since the alias ref doesn't include it on output.

Lastly, should we consider appending 'Variables' to the top much like we do for 'Styles' (color, gradient, font, typography, etc). This feels a bit scattered to me (My variable collections are 'palette, contextual, definitive'). Seems we'd want that to be 'variables/palette', etc.
Screenshot 2023-08-03 at 8 22 01 AM

I added a new discussion here

Sorry to come back to this so late.

Hello! I believe I have a solution for 'Cannot read properties of undefined (reading 'value') issue.

@dj-kmuldoon is this still an issue?

@lukasoppermann Suspect not, if nobody else is reporting. I've forked off and have since forgotten about the solution.