amzn / style-dictionary

A build system for creating cross-platform styles.
https://styledictionary.com
Apache License 2.0
3.94k stars 560 forks source link

fix: respect formatting.prefix scss formats #1294

Closed jorenbroekema closed 3 months ago

jorenbroekema commented 3 months ago

Issue #, if available: https://github.com/amzn/style-dictionary/issues/1286

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

aws-amplify-us-west-1[bot] commented 3 months ago

This pull request is automatically being deployed by Amplify Hosting (learn more).

Access this pull request here: https://pr-1294.d16eby4ekpss5y.amplifyapp.com

jorenbroekema commented 3 months ago

Oops, looks like some unrelated minor docs improvements made it into this branch, if it's okay I guess we can also merge those while we're at it?

jorenbroekema commented 3 months ago

Done, making sure the formatting options are all respected, even though it was a bit of opening a can of worms, because some of these formatting options are awkward, especially so in the context of a flat/deep map output.

I tried reusing createPropertyFormatter but this wasn't possible due to the nested nature of these formats. Suffix is already "respected" in the sense that for map-deep, the top part of it does reuse createPropertyFormatter, where suffix is respected. And in the deep-map below it, you wouldn't want the custom suffix to apply to the inner map syntax, both for flat/deep, that would break the SCSS syntax no matter what.

I think these formatting options are really awkward to be honest. Why would you ever want to change the separator if it breaks the output syntax? Same for prefix, this is better done as part of a token name transform, you're likely to break the output if you do it at the level of output property format. Same for suffix, this either breaks the output or you're better off adding a custom transform that adds a suffix to token values imo. Perhaps something to redesign for v5