⚠️ No Changeset found

Latest commit: 37774ec

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Hm I think I would prefer to make keeping the original object that's expanded as an opt-in, so:

{
  "foo": {
    "value": {
      "fontSize": "16px",
      "fontFamily": "Arial",
      "fontWeight": "Bold",
      "lineHeight": "1"
    },
    "type": "typography"
  }
}

becomes:

{
  "foo": {
    "fontSize": {
      "value": "16px",
      "type": "fontSizes"
    },
    "fontFamily": {
      "value": "Arial",
      "type": "fontFamilies"
    },
    "fontWeight": {
      "value": "Bold",
      "type": "fontWeights"
    },
    "lineHeight": {
      "value": "1",
      "type": "lineHeights"
    }
    "__sd_transforms_placeholder__": {
      "value": {
        "fontSize": "16px",
        "fontFamily": "Arial",
        "fontWeight": "Bold",
        "lineHeight": "1"
      },
      "type": "typography"
    }
  }
}

I'm thinking you might need that __sd_transforms_placeholder__ to wrap the "value" inside of, otherwise I fear the individual expanded props may be ignored by style-dictionary, because there's a "value" sibling prop. Not 100% about this, or what's the best way to work with it... but it should then result in:

:root {
  --foo-font-size: 16px;
  --foo-font-family: Arial;
  --foo-font-weight: 700;
  --foo-line-height: 1;
  --foo: 700 16px/1 Arial;
}

Hm I think I would prefer to make keeping the original object that's expanded as an opt-in, so:

I hear - that does end up with a cleaner object model, everything wrapped together nicely.
My concern with that is - what if another token references the original composite token? I think it's simplest to keep existing stuff where they are, and add new stuff separately.

I'm thinking you might need that sd_transforms_placeholder to wrap the "value" inside of, otherwise I fear the individual expanded props may be ignored by style-dictionary, because there's a "value" sibling prop. Not 100% about this, or what's the best way to work with it...

I'm getting dizzy 😵 😆
Right, if we could just keep the value as is, that would be great, but I also don't see how that could work.

My concern with that is - what if another token references the original composite token?

That's actually a really good question and I'm not sure at the moment about whether I added an integration test for that use case. If it turns out there's no clear path for this, then perhaps it makes sense that when expanding composite tokens, the original should always be kept intact for references. Then, it will not be an option, it'll be the default, after all, people could then filter those tokens out with StyleDictionary formats -> filters.

Either way, since you've spent some effort into this, I will make it a priority to dive into this topic as well and come up with a proper solution. The solution isn't that obvious so I want to start with some test cases and outline what the preferred behavior should be (including your case with referencing a composite token), and see if I can adjust the implementation code to align with the preferred behavior.

This PR kinda got lost a bit because it ended up being a tad more complicated than I foresaw when I first created the issue #128 , I added a comment that explains the issue and a potential way to solve it, let me know if you still want to work on this PR