Potential items to include:

• What it is
• Why Danny (Amazon?) made it
• Link to demo video
• Link to tutorial
• Link to explanation of structure of style dictionary JSON
• Link to list of options in using the style dictionary
• What is the customer problem we are solving?

Once the import framework is built, add support to import style from an existing android app

Maybe turn it on by default too? It would be nice to see what files are being generated in the stdout.

Pretty straightforward, like 'scss/variables' or 'css/variables' formats. Make sure to add unit tests.

The problem is with this line of logic:
https://github.com/amzn/style-dictionary/blob/master/lib/transform/property.js#L35

If the value is not a string, transforms will never run. The unit tests were not testing if transforms ran on non-string values, only that references to them were properly copied over.

Some of the formats (e.g. scss/variables javascript/es6) output flat dictionaries keyed by each properties name (as specified by a name transform like name/cti/camel). Other formats output the entire dictionary (e.g. javascript/umd or json) along with all the internal metadata. This behavior was surprising to me (despite the fact that I added javascript/umd myself heh). Here are a couple things I would expect from formatters:

• They respect any name transforms I supply to them
• They output only transformed property values, not internal dictionary metadata etc.

I don't know if these are reasonable expectations or, if so, what the best solution is. I mostly wanted to get the conversation started because it feels like the current state is inconsistent and makes certain usages impossible (e.g. getting a umd module with nice camelCaseProperties).

One potential solution: Any format that supports nested data structures (e.g. json, js) should use those structures IFF a name transform is not supplied. If a name transform is supplied then they should output flat data structures using the names that result from the name transform. The data under each key should always be just the transformed property value and should not include any dictionary metadata. If the user needs a raw dump of the dictionary they could use the actions API.

What are your thoughts? Am I just misunderstanding the API here?

Create a sketch plugin that allows an export to a style-dictionary collection of JSON files.

Once import framework is set up, add support to import from iOS styles of an existing app

Works

{
  "color": {
    "font": {
      "base": {
        "value": "{color.black.value}"
      }
    }
  }
}

Doesn't work:

{
  "color": {
    "font": {
      "base": {
        "value": "{ color.black.value }"
      }
    }
  }
}

Error Message

Error: Reference doesn't exist:  color.black.value

Set the config argument to be the current file object key/value pairs (out of the files array) flattened with the platform level key/value pairs.

This would be useful to see reference chain in the generated files. Although would need to only be used for files that have all properties in them or there might be errors.

Would help with extensibility to allow transformGroups to declare other transformGroups. For example:

StyleDictionary.registerTransformGroup({
  name: 'my-group',
  transforms: [
    'custom/transform',
    'scss'
  ]
});

That way, custom transforms don't need to redeclare the contents of an existing transform group when adding net-new transforms.

Error: Reference doesn't exist: size.border.width.sm.value

It could be more useful to also say where this reference is, right now you have to search for that reference in your code to fix the error. Here is where we throw that error:
https://github.com/amzn/style-dictionary/blob/master/lib/utils/resolveObject.js#L127

The 'static-style-guide/index.html' template has references to external css files here:

https://github.com/amzn/style-dictionary/blob/master/lib/common/templates/static-style-guide/index.html.template#L42

But we don't include those css files. We should package these files up somehow or reference raw files in our github repo or something. Open to ideas.

Installation should be super simple - a one line install (either via brew, npm, curl, or all three?), or a drag-n-drop installer familiar to people. Probably need to create for OS X, windows, and unix.

Start a framework for generating style dictionary from style in another format

Would it be useful to add in support to modify property references in a style dictionary?

Some examples:

• Having a base font size, and modify by multipliers
• Lighten or darken colors, although maybe not recommended because the developer would not have explicit control over exactly what the color will be. Multiply font sizes is easy to understand (16 * 1.5 = 24)
• Something else?

• Update dependencies if necessary
• Make sure package-lock.json, yarn.lock, and package.json files are in sync so that fresh installs are deterministic and don't change those files
• Update contribution docs to reflect the proper way to checkout the repo and install dependencies

https://github.com/amzn/style-dictionary/community

Examples:
https://github.com/angular/code-of-conduct/blob/master/CODE_OF_CONDUCT.md
https://github.com/todogroup/opencodeofconduct

In the spirit of the style dictionary, we shouldn't have to maintain documentation apart from the code itself. Whenever we add, remove, or change these default parts of the style dictionary, the documentation should be auto-generated.

It can difficult to debug if there are multiple 'reference doesn't exist' errors because it only fails on 1 error. One way to help would be to collect all reference errors before throwing, and outputting all the errors at once. Or the log config set to warn could just show warnings when references don't exist.

https://github.com/amzn/style-dictionary/blob/master/lib/utils/resolveObject.js#L127

Summary

While doing some custom implementation where I need to filter very granularly certain properties for specific platform I noticed that the filtering system seems to be applied on some templates only.
In iOS Templates we have:

Which basically takes whatever is coming from the configuration object as filter.

In Android, it's slightly different, color for instance:

It will only filter colors... but if we want to add a custom filter, we can't.

Proposals

1. Standardize filters within templates/formats to use whatever is in config and extend a certain configuration.

Example in Android:

Changes

var defaultFilter = {
  attributes: {
    category: "color"
  }
};
var props = _.filter(allProperties, Object.extend({}, this.filter, defaultFilter));

2. Add this filtering pre-processing to any transform; So we don't need to pre-filter at template/format level but the library does it automatically for everything.

Create tutorials to show how to use the framework.

1. A simple version that uses our example code and show changes making their way to iOS, Android, and web.
2. We should also have a step-by-step tutorial from scratch that goes more in-depth.
3. We should also have migration tutorials that show how to integrate the framework into existing codebases.

Quick timeline (2 minutes max):

• "Hi, I'm Danny, let me show you what style dictionary does for you"
• "here we can see the app I've built. here it is in iOS. And Android. And here is our style documentation."
• "Okay, now you've seen the app. Say that I've now decided that I want to change the default text to 16 point for readability." (make the change)
• "we've also decided to go with an orange theme instead of blue." (make the change)
• "I'm also adding a new font type for validation errors in forms" (add it)
• "Now I save the style dictionary. Everything rebuilds."
• "Lets go look at our app. here is iOS. Here is android. And here is our style documentation."

• should be able to edit JSON files by hand
• should be able to see what this looks like (html/css example?)
• should be able to modify configuration
• should be able to specify integration points with projects
• should be able to click a button and create / upload / save output files wherever

self explanatory

When we resolve property references in the JSON like "{color.font.base}", we resolve ALL references including the 'original' object which is meant to be an immutable copy of the original property. We do not want to resolve that reference.

Need to add unit tests to catch this.

Is "write" the right verb to use in this phrase?

Alternate phrase ideas:

• "Style once, use everywhere."
• "Design once, use everywhere."

So we have a place for people to land besides "here are the files"

We forgot to update documentation when we introduced that change to how registerAction works. Let's update that real quick. @chazzmoney will you do the honors as this was your code?

self explanatory I think. For the demo, we might be able to generate a new foodly logo for example.

Video here: https://www.youtube.com/watch?v=1HREvonfqhY

Add to:

• README.md
• docs/README.md

Acceptance Criteria

User should be able to supply a custom parser to the style dictionary to be used when reading property files. It should be done in a generic way so that any parser (yaml, hjson, and any other) could conceivably be used. A parser should be a function that takes a file (as a path string) as input, and outputs a JS object. Any function that follows this could be used as a parser.

How does this benefit the user?

Some do not like writing JSON, it can be verbose and not as simple as something like yaml. This will allow users to use any data formatting syntax to describe their style dictionaries. This fits in with the spirit of style dictionary in being flexible to accommodate any project/platform/framework. At its core, a style dictionary is a data structure for defining styles; the filetype the data structure is written in is irrelevant.

Once the import framework is built, add support for importing from less/scss

According to tenet 7, "Fail loudly", when property collisions happen we should error out. We don't want downstream inconsistencies to happen because someone mistakenly overrode a property.

Once the css/fonts format PR is included and the font faces can be generated, make sure we show the icons in the static style guide.

We have example code that has package.json files that reference the package version. We need to make sure to update those when we release a new version.

8 digit hex & rgba

Currently, when style dictionary tries to transform a value it does this:

if (transform.type === 'value' && property.value.indexOf('{') < 0)

lib/transform/property.js

However if you put a number as a value, which should make sense for unit-less numbers like line-height or milliseconds. I think we just need to add a check in there to make sure property.value is a string before testing for '{'

Some actions we might want to run asynchronously to speed up build times, others we might want to run synchronously in case there are later actions that depend on the output of previous actions. This will be a placeholder for thoughts on asynchronous v. synchronous actions.

You should add support for Xamarin Resource Dictionaries so that those of us who develop in Xamarin can utilize your wonderful tool.
Thanks

Objective-C is cool and all, but we should really have a swift example app as that is the future.

While adding some more testing I noticed that we don't run the tests on commit. It would good to add a pre-commit hook to run the tests so engineers don't have to rely on the CI to catch any integration issues. This also goes well with the 3rd point in the contribution guidelines
https://github.com/amzn/style-dictionary/blob/master/CONTRIBUTING.md#code-rules

I can quickly add this on a PR:
https://github.com/typicode/husky

Text colors, emojis, loading, and better messaging!

These formats are a bit better suited than raw JSON because they have nicer formatting and allow comments.

SyntaxError: Unexpected token } in JSON at position 365

This error doesn't say which JSON file the error is in and it makes it hard to debug the issue. Here is where that error happens:
https://github.com/amzn/style-dictionary/blob/master/lib/utils/combineJSON.js#L37

Maybe we could wrap it in a try/catch block and give a better error.

There should be a better way to clean build artifacts. Because you can generate files in any place, if you change paths around there might be zombie artifacts littered around.

Once import framework is setup, allow import from css

I've been trying to figure it out how to add a transparent variant of a color.
something like this:

{
  "color": {
    "base": {
      "transparent": { "value": "#DDFF3300"}
  }
}

Normally in CSS you would use the word transparent but I know that's not cross platform compatible, so I was thinking maybe of using the hex8 value in here, so a total transparent could be #00000000.
When I run this with

    scss: {
      transformGroup: 'scss',
      buildPath: 'build/',
      files: [{
        destination: 'scss/variables.scss',
        format: 'scss/variables',
      }],

I'm just getting the first 6 values due to this group only handling the transforms as hex. Is there a way to specify a custom transform at property level? or how would I go about this... searched a lot in the docs and I ended up a little bit more confused on how to handle this.