Re: [community-group] Native modes and theming support (#210)

@SorsOps Really interesting proposal, with a lot of flexibility I think.

We are actually in the midst of setting up a flexible white label design system, which should be able to support an arbitrary amount of themes/modifiers. In order to do this, we‘ve come up with a custom `style-dictionary` implementation that can take a config built around the idea of what is called `sets` in your proposal.

Our implementation is a work in progress and much simpler than the one above, but brings two key differences: 
- Instead of explicitly naming filenames, we work with glob patterns to be able to reduce the amount of LOC while keeping a human readable format.

- We are also able to filter the output based on a glob pattern that matches the name of each token. We implemented this, since we ran into situations where a designer might need a specific token (i.e. font-size for an icon font), that an engineer might not use (icons implemented as `svg` with a `…-dimension-height` token). This reduces bundle size.

As far as I understand your example, it is possible to granularly combine tokens from various inputs, but it isn’t possible to further filter them. This would mean the input token structure still influences the outcome, since you‘d need to carefully group certain tokens in certain files. I might be wrong though, so please feel free to clarify if thats the case!

- We are able to modify each token names to get rid of arbitrary token group names such as `default`, which Figma Tokens still requires since token names can’t share group names.

For reference, here is the (very simple) TS definition of the current config implementation: 

```
type ConfigToken = {
  path: string // Used as a glob pattern
  ignore?: string | string[] // Used as (a) glob ignore pattern(s)
  selector?: string // CSS Selector
  filename?: { // Filename modifier, used to create output folder structures
    prefix?: string
    suffix?: string
    replace?: {
      from: string
      to: string
    }[]
  }
  tokens?: {
    ignore: string[] // Mulitmatch pattern to ignore certain tokens
  }
}

type ConfigTokenGroup = {
  selector?: string // Optional CSS Selector for all entries in the group
  files: ConfigToken[]
  filename?: {  // Optional filename modifier for all entries in the group
    prefix?: string
    suffix?: string
    replace?: {
      from: string
      to: string
    }[]
  }
}

type ConfigOptions = {
  basePath?: strin
  fileType?: string
  log?: boolean
}

type TokenTransformConfig = {
  options: ConfigOptions
  tokens: {
    include?: ConfigToken[] | ConfigTokenGroup
    source?: ConfigToken[] | ConfigTokenGroup[]
  }
}
```
Taking cues from `style-dictionary`, tokens within `include` are always imported as values that might be referenced, whereas everything in  `source` is parsed and transformed separately.

I'm unsure how any of this would fit into the proposal, but I do think it might be generally useful.


-- 
GitHub Notification of comment by robinscholz
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/210#issuecomment-1569739557 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 31 May 2023 08:32:29 UTC