feat(compose): Add Jetpack Compose format

[bherbst]

Issue #: #478

Description of changes:
Add support for Jetpack Compose output via a new compose/object format and associated transforms.

Note: While Google is developing Compose with Android as the primary target, there is significant interest in supporting other platforms as well. JetBrains is already working with Google to support desktop applications, there is some experimental web support, and there are people who have been exploring iOS as well.

As a result, I have explicitly given the format and transforms names that do not reference Android. The only Android-specific bits in here right now are the Kotlin imports for the Compose classes and functions which are under androidx.compose.ui. Google has indicated they are working on better non-Android packaging so I expect this to evolve.

compose/object format

The compose/object format supports outputting all token types to a Kotlin object.

package com.example.tokens;

import androidx.compose.ui.graphics.Color
import androidx.compose.ui.unit.*

object StyleDictionary {
  val colorBackgroundDanger = Color(0xffffeae9)
  val sizeFontLarge = 24.00.sp
  val sizePaddingLarge = 16.00.dp
}

Transforms

The new compose transform group includes four new transforms:

• color/composeColor (e.g. val backgroundRed = Color(0xFFAA0000))
• size/compose/em (e.g. val spacingLarge = 28.em)
• size/compose/remToSp (e.g. val spacingLarge = 26.sp)
• size/compose/remToDp (e.g. val spacingLarge = 16.00.dp)

Future work:

There are a few things I'd like to improve in the future and would love feedback on:

• I would like to only add the imports we actually need in the format. Ideally the transforms would be able to tell the format which imports it needs (e.g. the size/compose/remToSp transform is the only one that would need the androidx.compose.ui.unit.sp import). This type of communication between the format and the transform isn't really supported in Style Dictionary right now.
• Support for themeable property and/or Kotlin classes. It would be very easy to add a Kotlin class format that would support overriding a property, but I only think that would be appropriate for themeable properties This becomes somewhat tricky if the input contains a mix of themeable and non-themeable properties.
• Dark mode - I'm not sure if Style Dictionary intends to support dark mode natively, or if this is something that will be left to examples that leverage custom transforms & formats. I have an initial pass at such an implementation here: Support for Android Jetpack Compose #478 (comment)

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

[dbanksdesign]

This looks great, thank you so much for all your work on this. I just had a minor comment on supporting outputReferences in the format.

[dbanksdesign]

You are creating the property formatter here, but not using it in your template code. Is that intended?

[bherbst]

Oops, you are definitely correct there- I had switched from using the property formatter to doing it all in the template so I could output the comment before the variable (the formatter's internals currently put it after the variable).

So I did have references working (and intended that to be the case), but forgot to move reference resolution. I'll revisit that, good catch!

[bherbst]

Speaking of which- the current property formatter does some switching on the different CSS outputs, but I was a little hesitant to add kotlin-specific handling as well. For something like moving the comments to before a variable vs. after do you have a preference of updating the formatter or handling it in the template?

[bherbst]

I have updated the compose format to use the formatter so reference are now getting output again. I ended up taking a middle path with the property formatter- I added support for a "none" comment style that suppresses the comment in the formatter.

Adding a "kotlin" or "javadoc" comment style to the existing set of "short" and "long" didn't feel right.

[dbanksdesign]

@bherbst I love the middle ground you took. I think it makes sense to me and balances the right level of flexibility in the format and formatHelper code. Great work!

[chazzmoney]

LGTM!