carbon-design-system · joshblack · Aug 7, 2018 · Jun 5, 2018 · Aug 1, 2018
diff --git a/.babelrc b/.babelrc
diff --git a/CODE_OF_CONDUCT.md → .github/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md → .github/CODE_OF_CONDUCT.md
@@ -4,13 +4,12 @@ This is a place to ask questions, work through any challenges, and share ideas a
 
 ### TLDR;
 
-* **Be respectful & understanding.** Not all of us will agree all the time, but disagreement is no excuse for poor behavior or poor manners. It is important that we resolve disagreements and differing views constructively.
-
+- **Be respectful & understanding.** Not all of us will agree all the time, but disagreement is no excuse for poor behavior or poor manners. It is important that we resolve disagreements and differing views constructively.
 
 * **Be welcoming.** We strive to be a community that welcomes and supports people of all backgrounds and identities.
 
+### General
 
-### General 
 Communication through any of Carbon's channels (GitHub, emails, Twitter, Slack) must be constructive and never resort to personal attacks, trolling, public or private harassment, insults, or other unprofessional conduct.
 
 We promise to extend courtesy and respect to everyone involved in this project, regardless of gender, gender identity, sexual orientation, disability, age, race, ethnicity, religion, or level of experience. We expect anyone contributing to Carbon to do the same.
@@ -20,18 +19,16 @@ If any member of the community violates this Code of Conduct, the maintainers of
 If you are subjected to or witness unacceptable behavior, or have any other concerns, please communicate with us directly via [email protected].
 
 ### Slack
-1. Please, no `@here` or `@channel` unless it is a bug that is **breaking production code.** We have communities in many different time zones, and we would hate to disrupt someone not at the office.
-2. There's no need to notify the Carbon team that you have made an issue in Carbon's GitHub repositories. We check these several times a day, so we promise we'll address your issue as soon as we can. 
-3. Reserve direct messages for sensitive discussions, such as privacy, legal, or HR reasons. Otherwise, we encourage posting in public channels so people with the same questions can benefit.
-4. If you have a pressing bug fix, it is best to make a PR directly to get your issues addressed. 
-5. `#carbon-components`: This channel is for questions about Carbon Components only. It is not the place to ask general coding questions. Instead, use a dev community like [StackOverflow](https://stackoverflow.com/). 
-6. `#carbon-design-system`: Please post any design questions with an in-context screen shot (i.e. screen shot of the whole UI you are designing) with background as to what you are trying to accomplish in this flow. We welcome in-progress work to get community design feedback as well. 
-
 
+1.  Please, no `@here` or `@channel` unless it is a bug that is **breaking production code.** We have communities in many different time zones, and we would hate to disrupt someone not at the office.
+2.  There's no need to notify the Carbon team that you have made an issue in Carbon's GitHub repositories. We check these several times a day, so we promise we'll address your issue as soon as we can.
+3.  Reserve direct messages for sensitive discussions, such as privacy, legal, or HR reasons. Otherwise, we encourage posting in public channels so people with the same questions can benefit.
+4.  If you have a pressing bug fix, it is best to make a PR directly to get your issues addressed.
+5.  `#carbon-components`: This channel is for questions about Carbon Components only. It is not the place to ask general coding questions. Instead, use a dev community like [StackOverflow](https://stackoverflow.com/).
+6.  `#carbon-design-system`: Please post any design questions with an in-context screen shot (i.e. screen shot of the whole UI you are designing) with background as to what you are trying to accomplish in this flow. We welcome in-progress work to get community design feedback as well.
 
-<hr> 
+<hr>
 
 If you have suggestions to improve this Code of Conduct, please submit an issue or PR.
 
-
 This Code of Conduct was adopted from the [Angular Project](https://github.com/angular/code-of-conduct/blob/master/CODE_OF_CONDUCT.md) and [Todo Open Code of Conduct](http://todogroup.org/opencodeofconduct/).
diff --git a/docs/contributing.md → .github/CONTRIBUTING.md b/docs/contributing.md → .github/CONTRIBUTING.md
@@ -3,8 +3,9 @@
 ## Requirements
 
 Set up your SSH Key GitHub Enterprise account and install node.js 4 or higher.
-* [Generating SSH Keys - GitHub](https://help.github.com/articles/generating-ssh-keys/)
-* [`nvm` (Node Version Manager)](https://github.com/creationix/nvm) to use the `Node 6`.
+
+- [Generating SSH Keys - GitHub](https://help.github.com/articles/generating-ssh-keys/)
+- [`nvm` (Node Version Manager)](https://github.com/creationix/nvm) to use the `Node 6`.
 
 Contributing to carbon-components requires that you can run this repo locally on your computer.
 
@@ -16,15 +17,15 @@ Prefix all class names with `#{$prefix}--` in SCSS, which is replaced with `bx--
 and design systems inheriting Carbon can override.
 This prefix prevents potential conflicts with class names from the user.
 
-__HTML__
+**HTML**
 
 ```html
 <div class="bx--inline-notification bx--inline-notification--error" role="alert">
   <div class="bx--inline-notification__details">...</div>
 </div>
 ```
 
-__SCSS__
+**SCSS**
 
 ```scss
 .#{$prefix}--inline-notification {
@@ -53,6 +54,7 @@ A nested element can use a new block name as long as the styles are independent
   <button class="bx--component-button">Button</button>
 </div>
 ```
+
 :point_up: The `#{$prefix}--component-button` class implies that this button has independent styles from its parent.
 Generally, it's preferred to start a new block.
 
@@ -68,7 +70,7 @@ Avoid names with multiple `__element` names:
 
 All components belong in `src/components` in their own folder.
 
-Name files and folders using __singular__ form; not plural.
+Name files and folders using **singular** form; not plural.
 
 ```
 button
@@ -82,18 +84,18 @@ Also note that all variants of a component can live in a single HBS, SCSS and JS
 For example, while there are many button variants (primary, secondary, etc.), they're all contained in those single source files in the button folder.
 
 Component variants can be specified by either:
-  * Adding an item to `variants` in `.config.js` file (In this case, a `.hbs` file whose basename is exactly the same as the component name should be defined)
-  * Adding a `.hbs` file to component directory (Note: If there is a `.hbs` file whose basename is exactly the same as the component name, other `.hbs` files has to be in `componentname--variantname.hbs` format)
-* `.hbs` files are rendered with the data given via `variants[n].context` property (see below)
-* Supported properties in `.config.js` are the following:
-  * [`default`](https://fractal.build/guide/components/configuration#default)
-  * [`variants`](https://fractal.build/guide/components/configuration#variant-properties) - An array of objects with the following properties:
-    * `name`
-    * `label`
-    * `notes`
-    * `context`
-    * (`preview` - Unlike [Fractal](https://fractal.build/guide/components/configuration#preview), this property should point to a `.hbs` file under `demo` directory or `src` directory, *without* `@` symbol)
 
+- Adding an item to `variants` in `.config.js` file (In this case, a `.hbs` file whose basename is exactly the same as the component name should be defined)
+- Adding a `.hbs` file to component directory (Note: If there is a `.hbs` file whose basename is exactly the same as the component name, other `.hbs` files has to be in `componentname--variantname.hbs` format)
+- `.hbs` files are rendered with the data given via `variants[n].context` property (see below)
+- Supported properties in `.config.js` are the following:
+  - [`default`](https://fractal.build/guide/components/configuration#default)
+  - [`variants`](https://fractal.build/guide/components/configuration#variant-properties) - An array of objects with the following properties:
+    - `name`
+    - `label`
+    - `notes`
+    - `context`
+    - (`preview` - Unlike [Fractal](https://fractal.build/guide/components/configuration#preview), this property should point to a `.hbs` file under `demo` directory or `src` directory, _without_ `@` symbol)
 
 ## Start Contributing
 
@@ -103,9 +105,9 @@ Go to [carbon-components](https://github.com/IBM/carbon-components) and click th
 
 ### 2. Clone Your Fork:
 
-1. Go to your [GitHub Repositories](https://github.com/settings/repositories).
-1. Click on `[your_github_username]/carbon-components`.
-1. Click on the `Clone or Download` button and copy the URL from the `Clone with SSH` option. It should start with `[email protected]...`
+1.  Go to your [GitHub Repositories](https://github.com/settings/repositories).
+1.  Click on `[your_github_username]/carbon-components`.
+1.  Click on the `Clone or Download` button and copy the URL from the `Clone with SSH` option. It should start with `[email protected]...`
 
 In your terminal:
 
@@ -131,14 +133,15 @@ git remote -v
 ```
 
 When you do `git remote -v`, you'll see these remotes:
-* `origin`: connection to your fork
-* `upstream`: connection to the original repo.
+
+- `origin`: connection to your fork
+- `upstream`: connection to the original repo.
 
 ### 4. Work in a Branch
 
-* Always work in a branch.
-* Submit pull requests from a branch.
-* All commits must follow the convention outlined [here](https://github.com/conventional-changelog/conventional-changelog/blob/v0.5.3/conventions/angular.md).
+- Always work in a branch.
+- Submit pull requests from a branch.
+- All commits must follow the convention outlined [here](https://github.com/conventional-changelog/conventional-changelog/blob/v0.5.3/conventions/angular.md).
 
 ### 5. Start the server
 
@@ -152,7 +155,6 @@ yarn dev
 
 Once it's done building, you can start editing source code or creating new components. The system is set up to automatically bundle your changes/additions. Visit http://localhost:3000 to see the changes happen on the fly.
 
-
 ### 6. Test your JavaScript code
 
 If you're contributing to our JavaScript code, test your changes by running our test commands:
@@ -181,22 +183,22 @@ gulp test:unit -f tests/spec/fab_spec.js
 
 Other options for testing are:
 
-* `-d`/`--debug`: Stop generating code coverage report. Useful to debug your code when running test.
-* `-k`/`--keepalive`: Keep running test runner even after test ends. Test will restart running when you make changes to any test files or any files under test.
-* `-v`/`--verbose`: Let Karma emit detailed log.
+- `-d`/`--debug`: Stop generating code coverage report. Useful to debug your code when running test.
+- `-k`/`--keepalive`: Keep running test runner even after test ends. Test will restart running when you make changes to any test files or any files under test.
+- `-v`/`--verbose`: Let Karma emit detailed log.
 
 ### 7. Test your HTML/CSS code for a11y
 
 If you're contributing to our HTML/CSS code, a11y compliance of your code should be tested.
 
 To do so - First, (if you haven't done already) set up an auth token for a11y rules, by:
 
-1. Create AAT token, by:
-  1. Go to https://aat.mybluemix.net/auth/
-  1. Enter IBM ID/password as you log into Bluemix
-  1. Accept user agreement
-  1. Hit Copy Authentication Token button
-1. `> sed -e "s|\${NPM_TOKEN}|(The token obtained in above step)|g" < .aat.yml.src > .aat.yml`
+1.  Create AAT token, by:
+1.  Go to https://aat.mybluemix.net/auth/
+1.  Enter IBM ID/password as you log into Bluemix
+1.  Accept user agreement
+1.  Hit Copy Authentication Token button
+1.  `> sed -e "s|\${NPM_TOKEN}|(The token obtained in above step)|g" < .aat.yml.src > .aat.yml`
 
 Then you can test your changes by running our test commands:
 
@@ -219,12 +221,14 @@ The a11y test may report potential issues that should be handled in application-
 When you're at a good stopping place and you're ready for feedback from other contributors and maintainers, **push your commits to your fork**:
 
 #### Commit Tip
-> __Writing commit messages__
+
+> **Writing commit messages**
 >
 > - `<type>` indicates the type of commit that's being made. This can be: `feat`, `fix`, `perf`, `docs`, `chore`, `style`, `refactor`
 > - `<scope>` The scope could be anything specifying place of the commit change or the thing(s) that changed.
 >
-> __Commit message format:__
+> **Commit message format:**
+
 ```
 <type>(<scope>): <subject>
 <BLANK LINE>
@@ -233,15 +237,15 @@ When you're at a good stopping place and you're ready for feedback from other co
 <footer>
 ```
 
-*Do not submit pull requests from the `master` branch of your fork.*
+_Do not submit pull requests from the `master` branch of your fork._
 
 ```
 git checkout -b { YOUR_BRANCH_NAME }
 git add .
 git commit -m "fix(table): IE11 positioning error" -m "Fixes #34"
 ```
 
-* [Close a commit via commit message](https://help.github.com/articles/closing-issues-via-commit-messages/)
+- [Close a commit via commit message](https://help.github.com/articles/closing-issues-via-commit-messages/)
 
 ```
 git push origin { YOUR_BRANCH_NAME }
@@ -252,25 +256,26 @@ In your browser, navigate to [IBM/carbon-components](https://github.com/IBM/carb
 > **Is it a Breaking Change?**
 
 > We want to respect semver.
-It's important to discern whether your pull request contains breaking changes or not.
-Sometimes, renaming or removing things in the code can result in breaking changes.
+> It's important to discern whether your pull request contains breaking changes or not.
+> Sometimes, renaming or removing things in the code can result in breaking changes.
 
 > Here are some examples of breaking changes...changing, renaming or removing any of the following:
-> * HTML attributes
-> * Folders or Files
-> * Any SCSS `@mixin`, `$variable` or `function`
-> * Any JS `function` or `class`
+>
+> - HTML attributes
+> - Folders or Files
+> - Any SCSS `@mixin`, `$variable` or `function`
+> - Any JS `function` or `class`
 
 > We also practice **graceful deprecation** when something is slated to be removed -- we mark it as deprecated in the current version and remove it in the next major version.
 
 Before you create a pull request, change the base branch depending on what kind of change you're submitting.
 
-* Pull requests with **non-breaking changes** like patches and minor updates use the `master` as the base branch.
-* Pull requests with **breaking changes** use the latest `major version number` branch as the base branch (i.e. `7.0.0` or whatever the next major version is).
+- Pull requests with **non-breaking changes** like patches and minor updates use the `master` as the base branch.
+- Pull requests with **breaking changes** use the latest `major version number` branch as the base branch (i.e. `7.0.0` or whatever the next major version is).
 
 Write a title and description then click "Create pull request"
 
-* [How to write the perfect pull request](https://github.com/blog/1943-how-to-write-the-perfect-pull-request)
+- [How to write the perfect pull request](https://github.com/blog/1943-how-to-write-the-perfect-pull-request)
 
 ### 9. Updating a Pull Request
 

diff --git a/.github/ISSUE_TEMPLATE.md b/.github/ISSUE_TEMPLATE.md
@@ -8,37 +8,28 @@
 
 Describe in detail the issue you're having. Is this a feature request (new component, new icon), a bug, or a general issue?
 
-
-> Is this issue related to a specific component? 
-
+> Is this issue related to a specific component?
 
 > What did you expect to happen? What happened instead? What would you like to see changed?
 
+> What browser are you working in?
 
-
-> What browser are you working in? 
-
-
-
-> What version of the Carbon Design System are you using? 
-
-
+> What version of the Carbon Design System are you using?
 
 > What offering/product do you work on? Any pressing ship or release dates we should be aware of?
 
-
 ## Steps to reproduce the issue
 
-1. Step one
-2. Step two
-3. Step three
-4. etc.
-
+1.  Step one
+2.  Step two
+3.  Step three
+4.  etc.
 
 ## Additional information
 
-* Screenshots or code
-* Notes
+- Screenshots or code
+- Notes
 
 ## Add labels
+
 Please choose the appropriate label(s) from our existing label list to ensure that your issue is properly categorized. This will help us to better understand and address your issue.
diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
@@ -1,24 +1,21 @@
-## Overview
+Closes #
 
-Resolves {{ issue number(s) here }}
+{{short description}}
 
-{{ Description about the PR }}
+#### Changelog
 
-{{ Include images and gifs when applicable }}
+**New**
 
-### Added
+- {{new thing}}
 
-{{ Description of things added }}
+**Changed**
 
-### Removed
+- {{change thing}}
 
-{{ Description of things removed }}
+**Removed**
 
-### Changed
+- {{removed thing}}
 
-{{ Description of things changed }}
-
-
-## Testing / Reviewing
+#### Testing / Reviewing
 
 {{ Add descriptions, steps or a checklist for how reviewers can verify this PR works or not }}
diff --git a/.github/SUPPORT.md b/.github/SUPPORT.md
@@ -0,0 +1,7 @@
+# Support
+
+If you run into an issue, sorry about that! We definitely want to make sure that
+your experience using the Carbon Design System is the best that it can be.
+
+When this happens, just create an issue on GitHub by filling out the template
+and we'll try our best to respond in a reasonable time.
diff --git a/.prettierrc b/.prettierrc