Deprecating templates (#152)

* Displaying a warning when using templates in the config or registerTemplate
* Moving built-in templates to formats

.eslintrc.json

@@ -1,4 +1,7 @@
 {
+  "parserOptions": {
+    "ecmaVersion": 6
+  },
   "env": {
     "node": true,
     "mocha": true

CONTRIBUTING.md

@@ -21,26 +21,26 @@ We are always happy to receive code and documentation contributions to the frame
 
 1. This framework is released under the [Apache license][license]. Any code you submit will be released under that license. For substantial contributions, we may ask you to sign a [Contributor License Agreement (CLA)][cla].
 2. For any significant features or API changes please reach out to us to avoid any duplicate effort.
-3. Adding to the included transforms, transformGroups, formats, and templates, please read [this section](#what-should-be-included).
+3. Adding to the included transforms, transformGroups, and formats, please read [this section](#what-should-be-included).
 
 
 ## Code Style
 
 We use ESLint on the code to ensure a consistent style. Any new code committed must pass our ESLint tests. Take a look at our [ESLint file][eslint].
 
 ### Code Rules
-1. **Do not mutate property names or values in a format or template.** Mutations like this should happen in a transformer.
-1. **Be as generic as possible.** Do not hard-code any values or configuration in formats or templates.
+1. **Do not mutate property names or values in a format.** Mutations like this should happen in a transformer.
+1. **Be as generic as possible.** Do not hard-code any values or configuration in formats.
 1. **Fail loudly.** Users should be aware if something is missing or configurations aren't correct. This will help debug any issues instead of failing silently.
 1. **Rely on few dependencies.** This framework is meant to be extended and allows for customization. We don't want to bring a slew of dependencies that most people don't need.
 
 ## What should be included?
 
 Anything that contributes to the idea of creating cross-platform styles.
 
-### What transforms/transform groups/formats/templates should be included?
+### What transforms/transform groups/formats should be included?
 
-If it has a generic and flexible enough use-case, it can be included. We would like to keep this type of code to a minimum because we don't want to be a swiss army knife that does everything out of the box. Instead, we want to focus on core tasks that are useful to the largest number of projects. The spirit of this framework is to allow flexibility and modularity so that anyone can fit it to their needs. This is why you can write your own transforms, formats, and templates with the register methods.
+If it has a generic and flexible enough use-case, it can be included. We would like to keep this type of code to a minimum because we don't want to be a swiss army knife that does everything out of the box. Instead, we want to focus on core tasks that are useful to the largest number of projects. The spirit of this framework is to allow flexibility and modularity so that anyone can fit it to their needs. This is why you can write your own transforms, and formats with the register methods.
 
 ### Where do things go?
 
@@ -51,7 +51,7 @@ We separate each function/method into its own file and group them into directori
 
 Any new features should implement the proper unit tests. We use mocha and chai to test our framework.
 
-If you are adding a new transform, action, format, or template, please add new unit tests. You can see examples in test/formats.
+If you are adding a new transform, action, or format: please add new unit tests. You can see examples in test/formats.
 
 
 [issues]: https://github.com/amzn/style-dictionary/issues

README.md

@@ -124,7 +124,7 @@ This tells the style dictionary build system how and what to build. The default
       "buildPath": "build/android/",
       "files": [{
         "destination": "font_dimens.xml",
-        "template": "android/fontDimens"
+        "format": "android/fontDimens"
       }]
     }
   }
@@ -140,8 +140,7 @@ This tells the style dictionary build system how and what to build. The default
 | 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 used to generate the file. Can be a built-in one or you can create your own. Must declare a format or a template. |
-| platform.file.template | String (optional) | Template used to generate the file. Can be a built-in one or you can create your own. [More on formats and templates](https://amzn.github.io/style-dictionary/formats_and_templates) |
+| platform.file.format | String (optional) | Format used to generate the file. Can be a built-in one or you can create your own. [More on formats](https://amzn.github.io/style-dictionary/#/formats) |
 | 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". |
 
@@ -256,7 +255,7 @@ The comment  will appear in the output files, where relevant or the output forma
 
 ## Extending
 
-The style dictionary build system is made to be extended. We don't know exactly how everyone will want to use style dictionaries in their project, which is why it is easy to create custom transforms, templates, and formats.
+The style dictionary build system is made to be extended. We don't know exactly how everyone will want to use style dictionaries in their project, which is why it is easy to create custom transforms and formats.
 
 ```javascript
 const StyleDictionary = require('style-dictionary').extend('config.json');
@@ -275,7 +274,7 @@ StyleDictionary.registerTransform({
 StyleDictionary.buildAllPlatforms();
 ```
 
-For more information on creating your own transforms, templates, and formats, take a look at our [docs](https://amzn.github.io/style-dictionary/).
+For more information on creating your own transforms and formats, take a look at our [docs](https://amzn.github.io/style-dictionary/).
 
 ## Mascot
 

__tests__/__configs/test.json

@@ -52,13 +52,13 @@
       "files": [
         {
           "destination": "android/colors.xml",
-          "template": "android/colors"
+          "format": "android/colors"
         },{
           "destination": "android/font_dimen.xml",
-          "template": "android/fontDimens"
+          "format": "android/fontDimens"
         },{
           "destination": "android/dimens.xml",
-          "template": "android/dimens"
+          "format": "android/dimens"
         }
       ],
       "actions": [
@@ -71,10 +71,10 @@
       "files": [
         {
           "destination": "style_dictionary.plist",
-          "template": "ios/plist"
+          "format": "ios/plist"
         },{
           "destination": "style_dictionary.h",
-          "template": "ios/macros"
+          "format": "ios/macros"
         }
       ]
     }

__tests__/buildFiles.test.js

@@ -97,10 +97,10 @@ describe('buildFiles', () => {
     ).toThrow('Build path must end in a trailing slash or you will get weird file names.');
   });
 
-  it('should throw if template or formatter missing', () => {
+  it('should throw if missing a format', () => {
     expect(
       buildFiles.bind(null, dictionary, platformWithoutFormatter),
-    ).toThrow('Please supply a template or formatter');
+    ).toThrow('Please supply a format');
   });
 
   it('should work without buildPath', () => {