-Get ready for the next release of Style Dictionary! 🚀 +What's new in Style Dictionary 3.0!
[](https://badge.fury.io/js/style-dictionary)
-[](https://github.com/amzn/style-dictionary/blob/master/CONTRIBUTING.md#submitting-pull-requests)
+[](https://github.com/amzn/style-dictionary/blob/main/CONTRIBUTING.md#submitting-pull-requests)
[](https://github.com/amzn/style-dictionary/actions/workflows/test.yml)
[](https://www.npmjs.com/package/style-dictionary)
# Style Dictionary
> *Style once, use everywhere.*
-A Style Dictionary uses design tokens to define styles once and use those styles on any platform or language. It provides a single place to create and edit your styles, and exports these properties to all the places you need - iOS, Android, CSS, JS, HTML, sketch files, style documentation, etc. It is available as a CLI through npm, but can also be used like any normal node module if you want to extend its functionality.
+A Style Dictionary uses design tokens to define styles once and use those styles on any platform or language. It provides a single place to create and edit your styles, and exports these tokens to all the places you need - iOS, Android, CSS, JS, HTML, sketch files, style documentation, etc. It is available as a CLI through npm, but can also be used like any normal node module if you want to extend its functionality.
-When you are managing user experiences, it can be quite challenging to keep styles consistent and synchronized across multiple development platforms and devices. At the same time, designers, developers, PMs and others must be able to have consistent and up-to-date style documentation to enable effective work and communication. Even then, mistakes inevitably happen and the design may not be implemented accurately. StyleDictionary solves this by automatically generating style definitions across all platforms from a single source - removing roadblocks, errors, and inefficiencies across your workflow.
+When you are managing user experiences, it can be quite challenging to keep styles consistent and synchronized across multiple development platforms and devices. At the same time, designers, developers, PMs and others must be able to have consistent and up-to-date style documentation to enable effective work and communication. Even then, mistakes inevitably happen and the design may not be implemented accurately. Style Dictionary solves this by automatically generating style definitions across all platforms from a single source - removing roadblocks, errors, and inefficiencies across your workflow.
For detailed usage head to https://amzn.github.io/style-dictionary
@@ -27,7 +27,7 @@ For detailed usage head to https://amzn.github.io/style-dictionary
* [Usage](#usage)
* [Example](#example)
* [Quick Start](#quick-start)
-* [Style Properties](#style-properties)
+* [Design Tokens](#design-tokens)
* [Extending](#extending)
* [Contributing](#contributing)
* [License](#license)
@@ -76,7 +76,7 @@ StyleDictionary.buildAllPlatforms();
The `.extend()` method is an overloaded method that can also take an object with the configuration in the same format as a config.json file.
```javascript
const StyleDictionary = require('style-dictionary').extend({
- source: ['properties/**/*.json'],
+ source: ['tokens/**/*.json'],
platforms: {
scss: {
transformGroup: 'scss',
@@ -96,10 +96,11 @@ StyleDictionary.buildAllPlatforms();
## Example
[Take a look at some of our examples](examples/)
-A style dictionary is a collection of style properties, key/value pairs that describe stylistic attributes like colors, sizes, icons, motion, etc. A style dictionary defines these style properties in JSON files, and can also include static assets like images and fonts. Here is a basic example of what the package structure can look like:
+A style dictionary is a collection of design tokens, key/value pairs that describe stylistic attributes like colors, sizes, icons, motion, etc. A style dictionary defines these design tokens in JSON or Javascript files, and can also include static assets like images and fonts. Here is a basic example of what the package structure can look like:
+
```
├── config.json
-├── properties/
+├── tokens/
│ ├── size/
│ ├── font.json
│ ├── color/
@@ -111,10 +112,11 @@ A style dictionary is a collection of style properties, key/value pairs that des
```
### config.json
-This tells the style dictionary build system how and what to build. The default file path is config.json in the root of the project, but you can name it whatever you want, you can pass in the `--config` flag.
+This tells the style dictionary build system how and what to build. The default file path is `config.json` or `config.js` in the root of the project, but you can name it whatever you want by passing in the `--config` flag to the [CLI](https://amzn.github.io/style-dictionary/#/using_the_cli).
+
```json
{
- "source": ["properties/**/*.json"],
+ "source": ["tokens/**/*.json"],
"platforms": {
"scss": {
"transformGroup": "scss",
@@ -135,13 +137,14 @@ This tells the style dictionary build system how and what to build. The default
}
}
```
+
| Attribute | Type | Description |
| :--- | :--- | :--- |
-| source | Array | Paths to the property json files. Can have globs. |
+| source | Array | An array of file path [globs](https://github.com/isaacs/node-glob) to design token files. Style Dictionary will do a deep merge of all of the token files, allowing you to organize your files files however you want. |
+| include | Array | An array of file path [globs](https://github.com/isaacs/node-glob) to design token files that contain default styles. The Style Dictionary uses this as a base collection of tokens. The tokens found using the "source" attribute will overwrite tokens found using include. |
| platforms | Object | Sets of platform files to be built. |
-| platforms | Array | Paths to the property json files. Can have globs. |
-| platform.transformGroup | String (optional) | Apply a group of transforms to the properties, must either define this or `transforms`. |
-| platform.transforms | Array (optional) | Transforms to apply sequentially to all properties. Can be a built-in one or you can create your own. |
+| platform.transformGroup | String (optional) | Apply a group of transforms to the tokens, must either define this or `transforms`. |
+| platform.transforms | Array (optional) | Transforms to apply sequentially to all tokens. Can be a built-in one or you can create your own. |
| platform.buildPath | String (optional) | Base path to build the files, must end with a trailing slash. |
| platform.files | Array (optional) | Files to be generated for this platform. |
| platform.file.destination | String (optional) | Location to build the file, will be appended to the buildPath. |
@@ -149,7 +152,8 @@ This tells the style dictionary build system how and what to build. The default
| platform.file.options | Object (optional) | A set of extra options associated with the file. |
| platform.file.options.showFileHeader | Boolean | If the generated file should have a "Do not edit + Timestamp" header (where the format supports it). By default is "true". |
-### Properties
+### Design Tokens
+
```json
{
"size": {
@@ -163,7 +167,7 @@ This tells the style dictionary build system how and what to build. The default
}
```
-Here we are creating some basic font size properties. The style definition size.font.small.value is "10px" for example. The style definition size.font.base.value is automatically aliased to the value found in size.font.medium.value and both of those resolve to "16px".
+Here we are creating some basic font size design tokens. The style definition size.font.small.value is "10px" for example. The style definition size.font.base.value is automatically aliased to the value found in size.font.medium.value and both of those resolve to "16px".
Now what the style dictionary build system will do with this information is convert it to different formats, enabling these values to be used in any type of codebase. From this one file you can generate any number of files like:
@@ -190,16 +194,21 @@ float const SizeFontBase = 16.00f;
## Quick Start
-The style dictionary framework comes with some example code to get you started. Install the node module globally, create a directory and `cd` into it.
+
+The style dictionary framework comes with some example code to get you stared. Install the node module globally, create a directory and `cd` into it.
+
```
$ npm i -g style-dictionary
$ mkdir MyStyleDictionary
$ cd MyStyleDictionary
```
+
Now run:
+
```
$ style-dictionary init basic
```
+
This command will copy over the example files found in [example](examples/) in this repo. Now you have an example project set up. You can make changes to the style dictionary and rebuild the project by running:
```
@@ -209,13 +218,13 @@ $ style-dictionary build
Take a look at the documentation for the example code.
-## Style Properties
+## Design Tokens
-A style property is an attribute to describe something visually. It is atomic (it cannot be broken down further). Style properties have a name, a value, and optional attributes or metadata. The name of a property can be anything, but we have a proposed naming structure that works really well in the next section.
+A design token is an attribute to describe something visually. It is atomic (it cannot be broken down further). Design tokens have a name, a value, and optional attributes or metadata. The name of a token can be anything, but we have a proposed naming structure that we find works really well in the next section.
### Category/Type/Item Structure
-While not exactly necessary, we feel this classification structure of style properties makes the most sense semantically. Style properties can be organized into a hierarchical tree structure with the top level, category, defining the primitive nature of the property. For example, we have the color category and every property underneath is always a color. As you proceed down the tree to type, item, sub-item, and state, you get more specific about what that color is. Is it a background color, a text color, or a border color? What kind of text color is it? You get the point. Now you can structure your property json files like simple objects:
+While not exactly necessary, we feel this classification structure of design tokens makes the most sense semantically. Design tokens can be organized into a hierarchical tree structure with the top level, category, defining the primitive nature of the token. For example, we have the color category and every token underneath is always a color. As you proceed down the tree to type, item, sub-item, and state, you get more specific about what that color is. Is it a background color, a text color, or a border color? What kind of text color is it? You get the point. Now you can structure your token json files like simple objects:
```
{
@@ -228,15 +237,15 @@ While not exactly necessary, we feel this classification structure of style prop
}
```
- The CTI is implicit in the structure, the category and type is 'size' and 'font', and there are 2 properties 'base' and 'large'.
+The CTI is implicit in the structure, the category and type is 'size' and 'font', and there are 2 tokens 'base' and 'large'.
- Structuring style properties in this manner gives us consistent naming and accessing of these properties. You don't need to remember if it is button_color_error or error_button_color, it is color_background_button_error!
+Structuring design tokens in this manner gives us consistent naming and accessing of these tokens. You don't need to remember if it is button_color_error or error_button_color, it is color_background_button_error!
- You can organize and name your style properties however you want, there are no restrictions. But we have a good amount of helpers if you do use this structure, like the 'attribute/cti' transform which adds attributes to the property of its CTI based on the path in the object. There are a lot of name transforms as well for when you want a flat structure like for Sass variables.
+You can organize and name your design tokens however you want, there are no restrictions. But we have a good amount of helpers if you do use this structure, like the 'attribute/cti' transform which adds attributes to the token of its CTI based on the path in the object. There are a lot of name transforms as well for when you want a flat structure like for Sass variables.
- Also, the CTI structure provides a good mechanism to target transforms for specific kinds of properties. All of the transforms provided by the framework use the CTI of a property to know if it should be applied. For instance, the 'color/hex' transform only applies to properties of the category 'color'.
+Also, the CTI structure provides a good mechanism to target transforms for specific kinds of tokens. All of the transforms provided by the framework use the CTI of a token to know if it should be applied. For instance, the 'color/hex' transform only applies to tokens of the category 'color'.
-You can also add a _comment_ to a style property:
+You can also add a _comment_ to a design token:
```
{
diff --git a/__integration__/README.md b/__integration__/README.md
new file mode 100644
index 000000000..f8d9415dd
--- /dev/null
+++ b/__integration__/README.md
@@ -0,0 +1,12 @@
+# Style Dictionary Integration Tests
+
+Style Dictionary is a tool to generate valid source code for multiple platforms and languages to consume. Because of this, unit testing can only get us so far. Simply unit testing or even basic snapshot testing of outputs doesn't give the whole picture.
+
+The integration tests here are meant to show complete end-to-end examples of Style Dictionary being used in order to validate the files it is generating.
+
+The integration tests still use Jest and snapshots, but rather than singling out format code, each test group builds a complete Style Dictionary and then tests the content of the output files with snapshots and validating syntax where possible.
+
+## To do
+
+* Jest snapshots are a good built-in way to test if content has changed, but storing the contents of a source code file like a CSS variables file doesn't get proper syntax highlighting and validation in IDEs. It would be better if we could store the raw output file and test against the new contents, but snapshot testing does not allow for that.
+* Add more syntax validations
\ No newline at end of file
diff --git a/__integration__/__snapshots__/android.test.js.snap b/__integration__/__snapshots__/android.test.js.snap
new file mode 100644
index 000000000..8d8a33582
--- /dev/null
+++ b/__integration__/__snapshots__/android.test.js.snap
@@ -0,0 +1,517 @@
+// Jest Snapshot v1, https://goo.gl/fbAQLP
+
+exports[`integration android android/resources should match snapshot 1`] = `
+"
+
+
+style-dictionary](#module_style-dictionary)
+
+
+
+
+Add a custom file header to the style dictionary. File headers are used in
+formats to display some information about how the file was built in a comment.
+
+
+| Param | Type | Description |
+| --- | --- | --- |
+| options | Object | |
+| options.name | String | Name of the format to be referenced in your config.json |
+| options.fileHeader | function | Function that returns an array of strings, which will be mapped to comment lines. It takes a single argument which is the default message array. See [file headers](formats.md#file-headers) for more information. |
+
+**Example**
+```js
+StyleDictionary.registerFileHeader({
+ name: 'myCustomHeader',
+ fileHeader: function(defaultMessage) {
+ return [
+ ...defaultMessage,
+ `hello, world!`
+ ];
+ }
+})
+```
+
+* * *
+
### registerFilter
> StyleDictionary.registerFilter(filter) ⇒ [style-dictionary](#module_style-dictionary)
@@ -192,14 +223,14 @@ Add a custom filter to the style dictionary
| --- | --- | --- |
| filter | Object | |
| filter.name | String | Name of the filter to be referenced in your config.json |
-| filter.matcher | function | Matcher function, return boolean if the property should be included. |
+| filter.matcher | function | Matcher function, return boolean if the token should be included. |
**Example**
```js
StyleDictionary.registerFilter({
name: 'isColor',
- matcher: function(prop) {
- return prop.attributes.category === 'color';
+ matcher: function(token) {
+ return token.attributes.category === 'color';
}
})
```
@@ -219,14 +250,40 @@ Add a custom format to the style dictionary
| --- | --- | --- |
| format | Object | |
| format.name | String | Name of the format to be referenced in your config.json |
-| format.formatter | function | Function to perform the format. Takes 2 arguments, `dictionary` and `config` Must return a string. Function is bound to its file object in the `platform.files` array. |
+| format.formatter | function | Function to perform the format. Takes a single argument. See [creating custom formats](formats.md#creating-formats) Must return a string, which is then written to a file. |
**Example**
```js
StyleDictionary.registerFormat({
name: 'json',
- formatter: function(dictionary, config) {
- return JSON.stringify(dictionary.properties, null, 2);
+ formatter: function({dictionary, platform, options, file}) {
+ return JSON.stringify(dictionary.tokens, null, 2);
+ }
+})
+```
+
+* * *
+
+### registerParser
+> StyleDictionary.registerParser(pattern, parse) ⇒ [style-dictionary](#module_style-dictionary)
+
+
+
+
+Adds a custom parser to parse style dictionary files
+
+
+| Param | Type | Description |
+| --- | --- | --- |
+| pattern | Regex | A file path regular expression to match which files this parser should be be used on. This is similar to how webpack loaders work. `/\.json$/` will match any file ending in '.json', for example. |
+| parse | function | Function to parse the file contents. Takes 1 argument, which is an object with 2 attributes: contents wich is the string of the file contents and filePath. The function should return a plain Javascript object. |
+
+**Example**
+```js
+StyleDictionary.registerParser({
+ pattern: /\.json$/,
+ parse: ({contents, filePath}) => {
+ return JSON.parse(contents);
}
})
```
@@ -267,7 +324,7 @@ StyleDictionary.registerTemplate({
Add a custom transform to the Style Dictionary
-Transforms can manipulate a property's name, value, or attributes
+Transforms can manipulate a token's name, value, or attributes
| Param | Type | Description |
@@ -275,22 +332,23 @@ Transforms can manipulate a property's name, value, or attributes
| transform | Object | Transform object |
| transform.type | String | Type of transform, can be: name, attribute, or value |
| transform.name | String | Name of the transformer (used by transformGroup to call a list of transforms). |
-| [transform.matcher] | function | Matcher function, return boolean if transform should be applied. If you omit the matcher function, it will match all properties. |
-| transform.transformer | function | Performs a transform on a property object, should return a string or object depending on the type. Will only update certain properties by which you can't mess up property objects on accident. |
+| transform.transitive | Boolean | If the value transform should be applied transitively, i.e. should be applied to referenced values as well as absolute values. |
+| [transform.matcher] | function | Matcher function, return boolean if transform should be applied. If you omit the matcher function, it will match all tokens. |
+| transform.transformer | function | Modifies a design token object. The transformer function will receive the token and the platform configuration as its arguments. The transformer function should return a string for name transforms, an object for attribute transforms, and same type of value for a value transform. |
**Example**
```js
StyleDictionary.registerTransform({
name: 'time/seconds',
type: 'value',
- matcher: function(prop) {
- return prop.attributes.category === 'time';
+ matcher: function(token) {
+ return token.attributes.category === 'time';
},
- transformer: function(prop) {
+ transformer: function(token) {
// Note the use of prop.original.value,
// before any transforms are performed, the build system
- // clones the original property to the 'original' attribute.
- return (parseInt(prop.original.value) / 1000).toString() + 's';
+ // clones the original token to the 'original' attribute.
+ return (parseInt(token.original.value) / 1000).toString() + 's';
}
});
```
diff --git a/docs/architecture.md b/docs/architecture.md
index fbd6e94c8..28bad20e6 100644
--- a/docs/architecture.md
+++ b/docs/architecture.md
@@ -1,4 +1,4 @@
-# Architecture Overview
+# Architecture
This is how Style Dictionary works under the hood.
@@ -8,11 +8,13 @@ Let's take a closer look into each of these steps.
## 1. Parse the config
-Style Dictionary is a configuration based framework, you tell it what to do in a configuration file. Style Dictionary first parses this configuration to know what to do.
+Style Dictionary is a configuration based framework, you tell it what to do in a configuration file. Style Dictionary first parses this [configuration](config.md) to know what to do.
## 2. Find all token files
-In your [config](config.md) file you define a `source`, which is an array of file paths. This tells Style Dictionary where to find your token files. You can have them anywhere and in any folder structure as long as you tell Style Dictionary where to find them.
+In your [config](config.md) file can define `include` and `source`, which are arrays of file path globs. These tell Style Dictionary where to find your token files. You can have them anywhere and in any folder structure as long as you tell Style Dictionary where to find them.
+
+If there are [custom parsers](parsers.md) defined, Style Dictionary will run those on files the parsers match.
## 3. Deep merge token files
@@ -20,18 +22,24 @@ Style Dictionary takes all the files it found and performs a deep merge. This al
## 4. Iterate over the platforms
-For each platform defined in your [config](config.md), Style Dictionary will do a few steps to get it ready to be consumed on that platform. You don't need to worry about one platform affecting another because everything that happens in a platform is non-destructive
+For each platform defined in your [config](config.md), Style Dictionary will do a few steps to get it ready to be consumed on that platform. You don't need to worry about one platform affecting another because everything that happens in a platform is non-destructive.
## 4a. Transform the tokens
Style Dictionary now traverses over the whole token object and looks for design tokens. It does this by looking for anything with a `value` key. When it comes across a design token, it then performs all the [transforms](transforms.md) defined in your [config](config.md) in order.
+Value transforms, transforms that modify a token's value, are skipped if the token references another token. Starting in 3.0, you can define a [transitive transform](transforms.md#transitive-transforms) that will transform a value that references another token after that reference has been resolved.
+
## 4b. Resolve aliases / references to other values
-After all the tokens have been transformed, it then does another pass over the token object looking for aliases, which look like `"{size.font.base.value}"`. When it finds these, it then replaces the reference with the transformed value. As we have a single complete token object, aliases can be in any token file and still work.
+After all the tokens have been transformed, it then does another pass over the token object looking for aliases, which look like `"{size.font.base.value}"`. When it finds these, it then replaces the reference with the transformed value. Because Style Dictionary merges all token files into a single object, aliases can be in any token file and still work.
## 4c. Format the tokens into files
Now all the design tokens are ready to be written to a file. Style Dictionary takes the whole transformed and resolved token object and for each file defined in the platform it [formats](formats.md) the token object and write the output to a file. Internally, Style Dictionary creates a flat array of all the design tokens it finds in addition to the token object. This is how you can output a flat SCSS variables file.
-After Style Dictionary does steps 4-6 for each platform, now you have all your output files that are ready to consume in each platform and codebase.
+## 4d. Run actions
+
+[Actions](actions.md) are custom code that run in a platform after the files are generated. They are useful for things like copying assets to specific build directories or generating images.
+
+After Style Dictionary does steps 4a-4d for each platform, you will have all your output files that are ready to consume in each platform and codebase.
diff --git a/docs/assets/styles.css b/docs/assets/styles.css
index 35a24813c..fa97f2d2c 100644
--- a/docs/assets/styles.css
+++ b/docs/assets/styles.css
@@ -284,7 +284,8 @@ section.cover .cover-main {
}
.markdown-section hr {
- border-bottom: 5px solid transparent;
+ width: 25%;
+ border-bottom: 5px solid #F1F1F2;
}
.token.punctuation {
@@ -363,6 +364,11 @@ section.cover .cover-main {
color: var(--theme-color-dark);
}
+.alert {
+ padding: 2rem;
+ border: 0.1rem solid var(--theme-color-secondary-light);
+}
+
/* Badges */
.markdown-section > p:first-child > a {
diff --git a/docs/build_process.md b/docs/build_process.md
deleted file mode 100644
index 95936a01d..000000000
--- a/docs/build_process.md
+++ /dev/null
@@ -1,16 +0,0 @@
-# Build Process
-
-Here is what the build system is doing under the hood.
-
-
-
-1. The build system reads in a configuration
-1. If there is an `includes` attribute in the config, it will take those files and deep merge them into the `properties` object
-1. It takes all the JSON files in the `source` attribute in the config and performs a deep merge onto the `properties` object
-1. Then it iterates over the platforms in the config and:
- 1. Performs all transforms, in order, defined in the transforms attribute or transformGroup
- 1. Builds all files defined in the files array
- 1. Performs any actions defined in the actions attribute
-
-# How to Build
-You can build a style dictionary [using the cli](using_the_cli.md) or [using the npm module](using_the_npm_module.md).
diff --git a/docs/config.md b/docs/config.md
index 7523a8443..ab185e647 100644
--- a/docs/config.md
+++ b/docs/config.md
@@ -1,17 +1,15 @@
# Configuration
-Style dictionaries are configuration driven. Your config file defines what executes and what to output when the style dictionary builds.
+Style dictionaries are configuration driven. Your configuration lets Style Dictionary know:
-By default, Style Dictionary looks for a `config.json` file in the root of your package. If not found, it looks for a `config.js` file in the root of your package. You can also specify a custom location when you use the [CLI](using_the_cli.md). If you want a custom build system using the [npm module](using_the_npm_module.md), you can specify a custom location for a configuration file or use a plain Javascript object.
+1. Where to find your [design tokens](tokens.md)
+1. How to transform and format them to generate output files
-## config.js
-You can find out more about creating configurations in JS in our documentation about using the [npm module](using_the_npm_module.md).
+Here is an example configuration:
-## config.json
- Here is a quick example:
```json
{
- "source": ["properties/**/*.json"],
+ "source": ["tokens/**/*.json"],
"platforms": {
"scss": {
"transformGroup": "scss",
@@ -35,20 +33,145 @@ You can find out more about creating configurations in JS in our documentation a
}
```
+## Configuration file formats
+
+Style Dictionary supports configuration files in these file formats:
+
+* JSON
+* JSON5
+* Javascript (CommonJS)
+
+Here is an example using a CommonJS module for configuration:
+
+```javascript
+// config.js
+module.exports = {
+ source: [`tokens/**/*.json`],
+ // If you don't want to call the registerTransform method a bunch of times
+ // you can override the whole transform object directly. This works because
+ // the .extend method copies everything in the config
+ // to itself, allowing you to override things. It's also doing a deep merge
+ // to protect from accidentally overriding nested attributes.
+ transform: {
+ // Now we can use the transform 'myTransform' below
+ myTransform: {
+ type: 'name',
+ transformer: (token) => token.path.join('_').toUpperCase()
+ }
+ },
+ // Same with formats, you can now write them directly to this config
+ // object. The name of the format is the key.
+ format: {
+ myFormat: ({dictionary, platform}) => {
+ return dictionary.allTokens.map(token => `${token.name}: ${token.value}`).join('\n');
+ }
+ },
+ platforms: {
+ // ...
+ }
+}
+```
+
+Some interesting things you can do in a CommonJS file that you cannot do in a JSON file:
+
+* Add custom transforms, formats, filters, actions, and parsers
+* Programmatically generate your configuration
+
+
+----
+
+
+## Using configuration files
+
+By default, the Style Dictionary [CLI](using_the_cli.md) looks for a `config.json` or `config.js` file in the root of your package.
+
+```json5
+// package.json
+"scripts": {
+ "build": "style-dictionary build"
+}
+```
+
+You can also specify a custom location when you use the [CLI](using_the_cli.md) with the `--config` parameter.
+
+```json5
+// package.json
+"scripts": {
+ "build": "style-dictionary build --config ./sd.config.js"
+}
+```
+
+## Using in Node
+
+You can also use Style Dictionary as an [npm module](using_the_npm_module.md) and further customize how Style Dictionary is run, for example running Style Dictionary multiple times with different configurations. To do this you would create a Javascript file that imports the Style Dictionary npm module and calls the [`.extend`](api.md#extend) and [`.buildAllPlatforms`](api.md#buildallplatforms) functions.
+
+```javascript
+// build.js
+const StyleDictionary = require('style-dictionary');
+
+const myStyleDictionary = StyleDictionary.extend({
+ // configuration
+});
+
+myStyleDictionary.buildAllPlatforms();
+
+// You can also extend Style Dictionary multiple times:
+const myOtherStyleDictionary = myStyleDictionary.extend({
+ // new configuration
+});
+
+myOtherStyleDictionary.buildAllPlatforms();
+```
+
+You would then change your npm script or CLI command to run that file with Node:
+
+```json5
+// package.json
+"scripts": {
+ "build": "node build.js"
+}
+```
+
+----
+
+
+## Attributes
+
| Attribute | Type | Description |
| :--- | :--- | :--- |
-| include | Array[String] (optional) | An array of path [globs](https://github.com/isaacs/node-glob) to Style Dictionary property files that contain default styles. The Style Dictionary uses this as a base collection of properties. The properties found using the "source" attribute will overwrite properties found using include. |
-| source | Array[String] | An array of path [globs](https://github.com/isaacs/node-glob) to JSON files that contain style properties. The Style Dictionary will do a deep merge of all of the JSON files, allowing you to separate your properties into multiple files. |
-| platforms | Object | An object containing platform config objects that describe how the Style Dictionary should build for that platform. You can add any arbitrary attributes on this object that will get passed to formats and actions (more on these in a bit). This is useful for things like build paths, name prefixes, variable names, etc. |
-| platform.transforms | Array[String] (optional) | An array of [transforms](transforms.md) to be performed on the style properties object. These will transform the properties in a non-destructive way, allowing each platform to transform the properties. Transforms to apply sequentially to all properties. Can be a built-in one or you can create your own. |
-| platform.transformGroup | String (optional) | A string that maps to an array of transforms. This makes it easier to reference transforms by grouping them together. You must either define this or [transforms](transforms.md). |
-| platform.buildPath | String (optional) | Base path to build the files, must end with a trailing slash. |
-| platform.files | Array (optional) | Files to be generated for this platform. |
-| platform.file.destination | String (optional) | Location to build the file, will be appended to the buildPath. |
-| platform.file.format | String (optional) | [Format](formats.md) used to generate the file. Can be a built-in one or you can create your own via [registerFormat](api.md#registerformat). |
-| platform.file.filter | String/Function/Object (optional) | A function, string or object used to filter the properties that will be included in the file. If a function is provided, each property will be passed to the function and the result (true or false) will determine whether the property is included. If an object is provided, each property will be matched against the object using a partial deep comparison. If a match is found, the property is included. If a string is passed, is considered a custom filter registered via [registerFilter](api.md#registerfilter) |
-| platform.file.options | Object (optional) | A set of extra options associated with the file. Only includes 'showFileHeader' at this time. |
-| platform.file.options.showFileHeader | Boolean | If the generated file should have a "Do not edit + Timestamp" header (where the format supports it). By default is "true". |
-| platform.actions | Array[String] (optional) | [Actions](actions.md) to be performed after the files are built for that platform. Actions can be any arbitrary code you want to run like copying files, generating assets, etc. You can use pre-defined actions or create custom actions. |
+| transform | Object (optional) | Custom [transforms](transforms.md) you can include inline rather than using `.registerTransform`. The keys in this object will be the transform's name, the value should be an object with `type`
+| format | Object (optional) | Custom [formats](formats.md) you can include inline in the configuration rather than using `.registerFormat`. The keys in this object will be for format's name and value should be the formatter function.
+| action | Object (optional) | Custom inline [actions](actions.md). The keys in this object will be the action's name and the value should be an object containing `do` and `undo` methods.
+| parsers | Array[Parser] (optional) | Custom [file parsers](parsers.md) to run on input files |
+| include | Array[String] (optional) | An array of file path [globs](https://github.com/isaacs/node-glob) to design token files that contain default styles. Style Dictionary uses this as a base collection of design tokens. The tokens found using the "source" attribute will overwrite tokens found using include. |
+| source | Array[String] | An array of file path [globs](https://github.com/isaacs/node-glob) to design token files. Style Dictionary will do a deep merge of all of the token files, allowing you to organize your files files however you want. |
+| tokens | Object | The tokens object is a way to include inline design tokens as opposed to using the `source` and `include` arrays.
+| properties | Object | **DEPRECATED** The properties object has been renamed to `tokens`. Using the `properties` object will still work for backwards compatibility.
+| platforms | Object[Platform] | An object containing [platform](#platform) config objects that describe how the Style Dictionary should build for that platform. You can add any arbitrary attributes on this object that will get passed to formats and actions (more on these in a bit). This is useful for things like build paths, name prefixes, variable names, etc.
-----
+### Platform
+
+A platform is a build target that tells Style Dictionary how to properly transform and format your design tokens for output to a specific platform. You can have as many platforms as you need and you can name them anything, there are no restrictions.
+
+| Attribute | Type | Description |
+| :--- | :--- | :--- |
+| transforms | Array[String] (optional) | An array of [transforms](transforms.md) to be performed on the design tokens. These will transform the tokens in a non-destructive way, allowing each platform to transform the tokens. Transforms to apply sequentially to all tokens. Can be a built-in one or you can create your own.
+| transformGroup | String (optional) | A string that maps to an array of transforms. This makes it easier to reference transforms by grouping them together. You must either define this or [transforms](transforms.md).
+| buildPath | String (optional) | Base path to build the files, must end with a trailing slash.
+| options | Object (optional) | Options that apply to all files in the platform, for example `outputReferences` and `showFileHeader`
+| files | Array[File] (optional) | [Files](#file) to be generated for this platform.
+| actions | Array[String] (optional) | [Actions](actions.md) to be performed after the files are built for that platform. Actions can be any arbitrary code you want to run like copying files, generating assets, etc. You can use pre-defined actions or create custom actions.
+
+### File
+
+A File configuration object represents a single output file. The `options` object on the file configuration will take precedence over the `options` object defined at the platform level.
+
+| Attribute | Type | Description |
+| :--- | :--- | :--- |
+| destination | String (optional) | Location to build the file, will be appended to the buildPath. |
+| format | String (optional) | [Format](formats.md) used to generate the file. Can be a built-in one or you can create your own via [registerFormat](api.md#registerformat). |
+| filter | String/Function/Object (optional) | A function, string or object used to filter the tokens that will be included in the file. If a function is provided, each design token will be passed to the function and the result (true or false) will determine whether the design token is included. If an object is provided, each design token will be matched against the object using a partial deep comparison. If a match is found, the design token is included. If a string is passed, is considered a custom filter registered via [registerFilter](api.md#registerfilter) |
+| options | Object (optional) | A set of extra options associated with the file. Includes `showFileHeader` and `outputReferences`. |
+| options.showFileHeader | Boolean | If the generated file should have a comment at the top about being generated. The default fileHeader comment has "Do not edit + Timestamp". By default is "true". |
+| options.fileHeader | String/Function (optional) | A custom fileHeader that can be either a name of a registered file header (string) or an inline [fileHeader](formats.md#customfileheader) function.
+| options.outputReferences | Boolean | If the file should keep token [references](formats.md#references-in-output-files). By default this is "false".
diff --git a/docs/examples.md b/docs/examples.md
index 5245e9523..f37209cc5 100644
--- a/docs/examples.md
+++ b/docs/examples.md
@@ -24,18 +24,29 @@ This is a more complete package and should have everything you need to get start
## Advanced
[View the folder](https://github.com/amzn/style-dictionary/tree/main/examples/advanced)
-If you want to look at more advanced examples of possible applications and customizations of Style Dictionary, the `examples/advanced` folder on GitHub contains these extra folders:
+If you want to look at more advanced examples of possible applications and customizations of Style Dictionary, the [`examples/advanced`](https://github.com/amzn/style-dictionary/tree/main/examples/advanced/) folder on GitHub contains these extra folders:
* [**assets-base64-embed**](https://github.com/amzn/style-dictionary/tree/main/examples/advanced/assets-base64-embed) shows how it's possible to embed and distribute assets – like images, icons and fonts – directly as design tokens.
-* [**auto-rebuild-watcher**](https://github.com/amzn/style-dictionary/tree/main/examples/advanced/auto-rebuild-watcher) shows how to setup a "watcher" that auto-rebuilds the tokens every time there is a change in the properties.
+* [**auto-rebuild-watcher**](https://github.com/amzn/style-dictionary/tree/main/examples/advanced/auto-rebuild-watcher) shows how to setup a "watcher" that auto-rebuilds the tokens every time there is a change in the tokens.
+* [**component-cti**](https://github.com/amzn/style-dictionary/tree/main/examples/advanced/component-cti) shows how to write component tokens and still use the CTI structure.
+* [**create-react-app**](https://github.com/amzn/style-dictionary/tree/main/examples/advanced/create-react-app) shows how to integrate Style Dictionary into a React application.
+* [**create-react-native-app**](https://github.com/amzn/style-dictionary/tree/main/examples/advanced/create-react-native-app) shows how to integrate Style Dictionary into a React Native application.
+* [**custom-file-header**](https://github.com/amzn/style-dictionary/tree/main/examples/advanced/custom-file-header) shows how to define custom file headers and use them in output files.
* [**custom-formats-with-templates**](https://github.com/amzn/style-dictionary/tree/main/examples/advanced/custom-formats-with-templates) shows how to generate custom output formats using templates, useful when you need to distribute your design tokens into your own pipelines or scripts.
-* [**custom-transforms**](https://github.com/amzn/style-dictionary/tree/main/examples/advanced/custom-transforms) shows how to use custom transforms (and transformGroups) to apply custom "transformations" to the properties when converted to design tokens.
-* [**multi-brand-multi-platform**](https://github.com/amzn/style-dictionary/tree/main/examples/advanced/multi-brand-multi-platform) shows how to set up Style Dictionary to support a multi-brand (for brand theming) and multi-platform (web, iOS, Android) solution, with property values depending on brand and platforms.
+* [**custom-parser**](https://github.com/amzn/style-dictionary/tree/main/examples/advanced/custom-parser) shows how to use custom parsers for token files.
+* [**custom-transforms**](https://github.com/amzn/style-dictionary/tree/main/examples/advanced/custom-transforms) shows how to use custom transforms (and transformGroups) to apply custom "transformations" to the design tokens.
+* [**flutter**](https://github.com/amzn/style-dictionary/tree/main/examples/advanced/flutter) shows how to integrate with Flutter applications.
+* [**matching-build-files**](https://github.com/amzn/style-dictionary/tree/main/examples/advanced/matching-build-files) shows how to output files 1-to-1 with source files.
+* [**multi-brand-multi-platform**](https://github.com/amzn/style-dictionary/tree/main/examples/advanced/multi-brand-multi-platform) shows how to set up Style Dictionary to support a multi-brand (for brand theming) and multi-platform (web, iOS, Android) solution, with token values depending on brand and platforms.
+* [**node-modules-as-config-and-properties**](https://github.com/amzn/style-dictionary/tree/main/examples/advanced/node-modules-as-config-and-properties) shows how to use Javascript rather than JSON for configuration and token files.
* [**npm-module**](https://github.com/amzn/style-dictionary/tree/main/examples/advanced/npm-module) shows how to set up a style dictionary as an npm module, either to publish to a local npm service or to publish externally.
+* [**referencing_aliasing**](https://github.com/amzn/style-dictionary/tree/main/examples/advanced/referencing_aliasing) shows how to use referencing (or "aliasing") to reference a value -or an attribute– of a token and assign it to the value –or attribute– of another token.
* [**s3**](https://github.com/amzn/style-dictionary/tree/main/examples/advanced/s3) shows how to set up a style dictionary to build files for different platforms (web, iOS, Android) and upload those build artifacts, together with a group of assets, to an S3 bucket.
-* [**referencing_aliasing**](https://github.com/amzn/style-dictionary/tree/main/examples/advanced/referencing_aliasing) shows how to use referencing (or "aliasing") to reference a value -or an attribute– of a property and assign it to the value –or attribute– of another property.
* [**tokens-deprecation**](https://github.com/amzn/style-dictionary/tree/main/examples/advanced/tokens-deprecation) shows one way to deprecate tokens by adding metadata to tokens and using custom formats to output comments in the generated files.
-* [**component-cti**](https://github.com/amzn/style-dictionary/tree/main/examples/advanced/component-cti) shows how to write component tokens and still use the CTI structure.
+* [**transitive-transforms**](https://github.com/amzn/style-dictionary/tree/main/examples/advanced/transitive-transforms) shows how to use transitive transforms to transform references
+* [**variables-in-outputs**](https://github.com/amzn/style-dictionary/tree/main/examples/advanced/variables-in-outputs) shows you how to use the `outputReferences` option to generate files variable references in them.
+* [**yaml-tokens**](https://github.com/amzn/style-dictionary/tree/main/examples/advanced/yaml-tokens) shows how to use a custom parser to define your source files in YAML rather than JSON.
+
---
diff --git a/docs/extending.md b/docs/extending.md
index 83a8c76a5..3222e47f8 100644
--- a/docs/extending.md
+++ b/docs/extending.md
@@ -9,6 +9,7 @@ There is a straightforward way to extend Style Dictionary to meet your needs - s
* [registerFormat](api.md#registerformat)
* [registerTemplate](api.md#registertemplate) (deprecated)
* [registerAction](api.md#registeraction)
+* [registerParser](api.md#registerparser)
## Extension Examples
Importing a configuration, defining a new `time/seconds` transform, and building the style dictionary.
diff --git a/docs/formats.md b/docs/formats.md
index 0fa1aba81..7e49f936b 100644
--- a/docs/formats.md
+++ b/docs/formats.md
@@ -8,13 +8,13 @@ Formats define the output of your created files. For example, to use your styles
you use the `css/variables` format. This will create a CSS file containing the variables from
your style dictionary.
-### Using formats
+## Using formats
You use formats in your config file under platforms > [platform] > files > [file] > format
```json
{
- "source": ["properties/**/*.json"],
+ "source": ["tokens/**/*.json"],
"platforms": {
"css": {
"transformGroup": "css",
@@ -31,13 +31,13 @@ You use formats in your config file under platforms > [platform] > files > [file
There is an extensive (but not exhaustive) list of [included formats](#pre-defined-formats) available in Style Dictionary.
-### Format configuration
+## Format configuration
Formats can take configuration to make them more flexible. This allows you to re-use the same format multiple times with different configurations or to allow the format to use data not defined in the tokens themselves. To configure a format, add extra attributes on the file object in your configuration like the following:
```json
{
- "source": ["properties/**/*.json"],
+ "source": ["tokens/**/*.json"],
"platforms": {
"scss": {
"transformGroup": "scss",
@@ -53,13 +53,13 @@ Formats can take configuration to make them more flexible. This allows you to re
In this example we are adding the `mapName` configuration to the `scss/map-deep` format. This will change the name of the SCSS map in the output. Not all formats have the configuration options; format configuration is defined by the format itself. To see the configurtion options of a format, take a look at the documentation of the [specific format](#pre-defined-formats)
-### Filtering tokens
+## Filtering tokens
A special file configuration is `filter`, which will filter the tokens before they get to the format. This allows you to re-use the same format to generate multiple files with different sets of tokens. Filtering tokens works by adding a `filter` attribute on the file object, where `filter` is:
* An object which gets passed to [Lodash's filter method](https://lodash.com/docs/4.17.14#filter).
* A string that references the name of a registered filter, using the [`registerFilter`](api.md#registerfilter) method
-* A function if you are defining your configuration in Javascript rather than JSON. The filter function takes a token as the property and should return a boolean if the token should be included (true) or excluded (false).
+* A function that takes a token and returns a boolean if the token should be included (true) or excluded (false). **This is only available if you are defining your configuration in Javascript.**
```javascript
{
@@ -71,24 +71,554 @@ A special file configuration is `filter`, which will filter the tokens before th
}
```
-### Creating formats
+The design token that is passed to the filter function has already been [transformed](transforms.md) and has [default metadata](tokens.md?id=default-design-token-metadata) added by Style Dictionary.
-You can create custom formats using the [`registerFormat`](api.md#registerformat) function. If you want to add configuration to your custom format, `this` is bound to the file object. Using this, you can access attributes on the file object with `this.myCustomAttribute` if the file object looks like:
+## References in output files
+
+Starting with version 3.0, some formats can keep the references in the output. This is a bit hard to explain, so let's look at an example. Say you have this very basic set of design tokens:
+
+```json5
+// tokens.json
+{
+ "color": {
+ "red": { "value": "#ff0000" },
+ "danger": { "value": "{color.red.value}" },
+ "error": { "value": "{color.danger.value}" }
+ }
+}
+```
+
+With this configuration:
+
+```json5
+// config.json
+{
+ "source": ["tokens.json"]
+ "platforms": {
+ "css": {
+ "transformGroup": "css",
+ "files": [{
+ "destination": "variables.css",
+ "format": "css/variables",
+ "options": {
+ // Look here 👇
+ "outputReferences": true
+ }
+ }]
+ }
+ }
+}
+```
+
+This would be the output:
+
+```css
+:root {
+ --color-red: #ff0000;
+ --color-danger: var(--color-red);
+ --color-error: var(--color-danger);
+}
+```
+
+The css variables file now keeps the references you have in your Style Dictionary! This is useful for outputting themeable and dynamic code.
+
+Without `outputReferences: true` Style Dictionary would resolve all references and the output would be:
+
+```css
+:root {
+ --color-red: #ff0000;
+ --color-danger: #ff0000;
+ --color-error: #ff0000;
+}
+```
+
+Not all formats use the `outputReferences` option because that file format might not support it (like JSON for example). The current list of formats that handle `outputReferences`:
+
+* [css/variables](#cssvariables)
+* [scss/variables](#scssvariables)
+* [less/variables](#lessvariables)
+* [android/resources](#androidresources)
+* [compose/object](#composeobject)
+* [ios-swift/class.swift](#ios-swiftclassswift)
+* [flutter/class.dart](#flutterclassdart)
+
+You can create custom formats that output references as well. See the [Custom format with output references](#custom-format-with-output-references) section.
+
+## File headers
+
+By default Style Dictionary adds a file header comment in the top of files built using built-in formats like this:
+
+```js
+// Do not edit directly
+// Generated on Sat, 01 Jan 2000 00:00:00 GMT
+```
+
+You can remove these comments with the option: `showFileHeader: false` if you do not want them in your generated files. You can also create your own file header or extend the default one. This could be useful if you want to put a version number or hash of the source files rather than a timestamp.
+
+Custom file headers can be added the same way you would add a custom format, either by using the [`registerFileHeader`](api.md#registerfileheader) function or adding the fileHeader object directly in the Style Dictionary [configuration](config.md). Your custom file header can be used in built-in formats as well as custom formats. To use a custom file header in a custom format see the [`fileHeader`](formats.md#fileheader) format helper method.
+
+```js
+const StyleDictionary = require('style-dictionary');
+StyleDictionary.registerFileHeader({
+ name: 'myCustomHeader',
+ fileHeader: (defaultMessage) => {
+ // defaultMessage are the 2 lines above that appear in the default file header
+ // you can use this to add a message before or after the default message 👇
+
+ // the fileHeader function should return an array of strings
+ // which will be formatted in the proper comment style for a given format
+ return [
+ ...defaultMessage,
+ `hello?`,
+ `is it me you're looking for?`,
+ ]
+ }
+});
+```
+
+Then you can use your custom file header in a file similar to a custom format:
+
+```json5
+{
+ source: ['tokens/**/*.json'],
+ platforms: {
+ css: {
+ transformGroup: 'css',
+ files: [{
+ destination: 'variables.css',
+ format: 'css/variables',
+ options: {
+ fileHeader: 'myCustomHeader'
+ }
+ }]
+ }
+ }
+}
+```
+
+Which should output a file that will start like this:
+
+```css
+/**
+ * Do not edit directly
+ * Generated on Thu, 18 Mar 2021 21:30:47 GMT
+ * hello?
+ * is it me you're looking for?
+ */
+```
+
+For an in-depth example see the [custom-file-header](https://github.com/amzn/style-dictionary/examples/advanced/custom-file-header) example.
+
+## Custom formats
+
+You can create custom formats using the [`registerFormat`](api.md#registerformat) function or by directly including them in your [configuration](config.md). A format has a name and a formatter function, which takes an object as the argument and should return a string which is then written to a file.
+
+### formatter
+> format.formatter(args) ⇒ String
+
+The formatter function that is called when Style Dictionary builds files.
+
+| Param | Type | Description | +
|---|---|---|
| args | Object | A single argument to support named parameters and destructuring. + |
+
| args.dictionary | Object | The transformed and resolved dictionary object + |
+
| args.dictionary.tokens | Object | Object structure of the tokens that has been transformed and references resolved. + |
+
| args.dictionary.allTokens | Array | Flattened array of all the tokens. This makes it easy to output a list, like a list of SCSS variables. + |
+
| args.dictionary.usesReference | function | Use this function to see if a token's value uses a reference. This is the same function style dictionary uses internally to detect a reference. + |
+
| args.dictionary.getReferences | function | Use this function to get the tokens that it references. You can use this to output a reference in your custom format. For example: |
+
| args.platform | Object | The platform configuration this format is being called in. + |
+
| args.file | Object | The file configuration this format is being called in. + |
+
| args.options | Object | Merged options object that combines platform level configuration and file level configuration. File options take precedence. + |
+
this in the formatter function is bound to the file object and when Style Dictionary calls the formatter function it passes 3 arguments: dictionary, platform, and file. Starting in 3.0 all data the formatter needs is in the first argument as shown above to make it easier to grab the arguments by name rather than by position. We recommend not using this or the positional arguments in your custom format.
+function
+
+Creates a function that can be used to format a property. This can be useful
+to use as the function on `dictionary.allTokens.map`. The formatting
+is configurable either by supplying a `format` option or a `formatting` object
+which uses: prefix, indentation, separator, suffix, and commentStyle.
+
+| Param | Type | Description | +
|---|---|---|
| options | Object | + |
| options.outputReferences | Boolean | Whether or not to output references. You will want to pass this from the |
+
| options.dictionary | Dictionary | The dictionary object sent to the formatter function + |
+
| options.format | String | Available formats are: 'css', 'sass', 'less', and 'stylus'. If you want to customize the format and can't use one of those predefined formats, use the |
+
| options.formatting | Object | Custom formatting properties that define parts of a declaration line in code. The configurable strings are: prefix, indentation, separator, suffix, and commentStyle. Those are used to generate a line like this: |
+
String
+
+This is for creating the comment at the top of generated files with the generated at date.
+It will use the custom file header if defined on the configuration, or use the
+default file header.
+
+| Param | Type | Description | +
|---|---|---|
| options | Object | + |
| options.file | File | The file object that is passed to the formatter. + |
+
| options.commentStyle | String | The only options are 'short' and 'xml', which will use the // or <!-- --> style comments respectively. Anything else will use /* style comments. + |
+
| options.formatting | Object | Custom formatting properties that define parts of a comment in code. The configurable strings are: prefix, lineSeparator, header, and footer. + |
+
String
+
+This is used to create lists of variables like Sass variables or CSS custom properties
+
+| Param | Type | Description | +
|---|---|---|
| options | Object | + |
| options.format | String | What type of variables to output. Options are: css, sass, less, and stylus + |
+
| options.dictionary | Object | The dictionary object that gets passed to the formatter method. + |
+
| options.outputReferences | Boolean | Whether or not to output references + |
+
| options.formatting | Object | Custom formatting properties that define parts of a declaration line in code. This will get passed to |
+
String
+
+This is used to create CSS (and CSS pre-processor) lists of icons. It assumes you are
+using an icon font and creates helper classes with the :before pseudo-selector to add
+a unicode character.
+__You probably don't need this.__
+
+| Param | Type | Description | +
|---|---|---|
| prefix | String | Character to prefix variable names, like '$' for Sass + |
+
| allTokens | Array.<Token> | allTokens array on the dictionary object passed to the formatter function. + |
+
| options | Object | options object passed to the formatter function. + |
+
Object
+
+Outputs an object stripping out everything except values
+
+| Param | Type | Description | +
|---|---|---|
| obj | Object | The object to minify. You will most likely pass |
+
Integer
+
+A sorting function to be used when iterating over `dictionary.allTokens` in
+a format.
+
+**Returns**: Integer - -1 or 1 depending on which element should come first based on https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort
+| Param | Type | Description | +
|---|---|---|
| a | * | first element for comparison + |
+
| b | * | second element for comparison + |
+
function
+
+A function that returns a sorting function to be used with Array.sort that
+will sort the allTokens array based on references. This is to make sure
+if you use output references that you never use a reference before it is
+defined.
+
+| Param | Type | +
|---|---|
| dictionary | Dictionary |
+
| Param | Type | Default | Description | +
|---|---|---|---|
| options | Object | + | |
| [options.showFileHeader] | Boolean | true | Whether or not to include a comment that has the build date + |
+
| [options.outputReferences] | Boolean | false | Whether or not to keep references (a -> b -> c) in the output. + |
+
| Param | Type | Default | Description | +
|---|---|---|---|
| options | Object | + | |
| [options.showFileHeader] | Boolean | true | Whether or not to include a comment that has the build date + |
+
| [options.outputReferences] | Boolean | false | Whether or not to keep references (a -> b -> c) in the output. + |
+
| Param | Type | Default | Description | +
|---|---|---|---|
| options | Object | + | |
| [options.showFileHeader] | Boolean | true | Whether or not to include a comment that has the build date + |
+
| [options.outputReferences] | Boolean | false | Whether or not to keep references (a -> b -> c) in the output. + |
+
| Param | Type | Default | Description | +
|---|---|---|---|
| options | Object | + | |
| [options.showFileHeader] | Boolean | true | Whether or not to include a comment that has the build date + |
+
| [options.outputReferences] | Boolean | false | Whether or not to keep references (a -> b -> c) in the output. + |
+
| Param | Type | Default | Description | +
|---|---|---|---|
| className | String | The name of the generated Kotlin object + |
+ |
| packageName | String | The package for the generated Kotlin object + |
+ |
| options | Object | + | |
| [options.showFileHeader] | Boolean | true | Whether or not to include a comment that has the build date + |
+
| [options.outputReferences] | Boolean | false | Whether or not to keep references (a -> b -> c) in the output. + |
+
| Param | Type | Default | Description | +
|---|---|---|---|
| options | Object | + | |
| [options.showFileHeader] | Boolean | true | Whether or not to include a comment that has the build date + |
+
| [options.outputReferences] | Boolean | false | Whether or not to keep references (a -> b -> c) in the output. + |
+
| Param | Type | Default | Description | +
|---|---|---|---|
| options | Object | + | |
| [options.showFileHeader] | Boolean | true | Whether or not to include a comment that has the build date + |
+
| [options.outputReferences] | Boolean | false | Whether or not to keep references (a -> b -> c) in the output. + |
+