Open brian-mcallister-lab49 opened 2 years ago
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:
What do you think about this approach?
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 https://github.com/amzn/style-dictionary/issues/757 and https://github.com/amzn/style-dictionary/issues/643#issuecomment-1072812903 (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.
The latest version of the spec changes the format of design tokens to follow these rules:
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):
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
$
.