lukasoppermann/design-tokens

Export format following latest spec updates.

Opened this issue · 2 comments

brian-mcallister-lab49 commented

The latest version of the spec changes the format of design tokens to follow these rules:

An object with a $value property is a token. Thus, $value is a reserved word in our spec, meaning you can't have a token whose name is "$value". The parent object's key is the token name.

This is a pretty recent change, but looks like this is how design tokens will be structured going forward. It looks like all "top level" keys in a design token object are now intended to be prefixed with $.

Inspecting this codebase a bit, it looks like all of the keys in the design token objects are defined in this file: https://github.com/lukasoppermann/design-tokens/blob/main/src/transformer/standardTransformer.ts

Would it make sense to take an approach such as the following (from these lines):

const VALUE_KEY = "$value";
const TYPE_KEY = "$type";

const widthToDimensionTransformer = ({ values }): StandardTokenDataInterface => ({
  [VALUE_KEY]: values.width.value,
  [TYPE_KEY]: 'dimension' as StandardTokenTypes
})

I'm still getting my head around the rest of the spec here, but it doesn't look like making this change (for all the various new keys) would break things like composite types, since the nested values are not prefixed with the $.

lukasoppermann commented

Hey @brian-mcallister-lab49 very interesting. I generally agree with your approach using const VALUE_KEY = "$value";
It may be best to create a config file for storing those names. The same config file could be added to the transformer package.

However I think this will be a lot of breakage for existing users and figma sadly is really bad when it comes to versioning of plugins.

So what I am currently thinking:

  1. rename old standard format to draft version x.z.y (whatever it was)
  2. create a new standard format with draft x.y.z. (latest) <- this will be changed

What do you think about this approach?

brian-mcallister-lab49 commented

Seems like a great plan.

Just a note though, I don't think style-dictionary supports this updated format yet.

There's a few mentions of this in their issues (see amzn/style-dictionary#757 and amzn/style-dictionary#643 (comment) (which references the spec, but this comment was written before the latest changes)), but I don't see anything that references plans to implement support for these changes.

I wouldn't say that fact is a blocker for implementing support in this plugin, per se, but it could be a bit confusing for users of this plugin since it "won't work" with any of the translation tools out there (Theo and style-dictionary at least, Diez is much less clear and I don't understand Specify at all).

Personally, I don't want to write any code at all, I'd rather just glue together libraries via GitHub Actions. In fact, I have a separate feature request to turn the https://github.com/lukasoppermann/design-token-transformer project into a GitHub Action that I can use in my project.

  • 👍1