Strings get converted to unquoted strings in scss & css

Hey,

I noticed that all strings end up being unquoted, for example:

textCase: {
  value: "uppercase"
}

Will show up in the css file as:

  --body-text-case: uppercase;

[lukasoppermann]

Hey @tonyjwalt I think this is an interesting solution for me.

@dbanksdesign to clarify where I am coming from.

I am currently working on a figma design token export plugin. I would like to ideally export a json file that can be converted by style-dictionary without any additional magic from my side.

CTI seems a bit limiting, as by default in Figma things like font styles include sizes, fonts and other things. If I understand you correct, I would have to include the “font-family” under the specific category content while the fontSize would be under the category size. Is this correct?

Currently I have a json (before trying to transform it for style-dictionary) that looks like this:

"body": {
    "h3": {
      "description": null,
      "values": {
        "fontSize": {
          "value": 20,
          "unit": "pixels"
        },
        "textDecoration": {
          "value": "none"
        },
        "fontFamily": {
          "value": "Roboto"
        },
        "fontStyle": {
          "value": "Medium"
        },
        "letterSpacing": {
          "value": 2,
          "unit": "percent"
        },
        "lineHeight": {
          "value": 160.0000023841858,
          "unit": "percent"
        },
        "paragraphIndent": {
          "value": 5,
          "unit": "pixels"
        },
        "paragraphSpacing": {
          "value": 8,
          "unit": "pixels"
        },
        "textCase": {
          "value": "uppercase"
        }
      }
    }

I think it would make sense to have this converted into tokens like:

--font-body-h3-fontSize: 20px;
--font-body-h3-textDecoration: none;
--font-body-h3-fontFamily: "Roboto"; 

Does this make sense? Or am I missing something here?

[tonyjwalt]

CSS seemed to be an odd one for us because some strings cannot be wrapped in quotes, while it’s required for others. On my team we thought this behavior was a format thing, so we built a solution into our custom formatter. You can see that in PR 428 in the formatter file on line 32.

We applied a solution similar to what @dbanksdesign recommended, but used data-type on the attributes object instead of just type. We felt it was descriptive of an attribute of the token and this also allowed us to mix and match a token’s type with the type of data used to define it.

As @dbanksdesign said, there are several ways to solve it. I just thought I’d share what we did if it helps.