[CHORE] Run Prettier on the other files in the project

.editorconfig

@@ -6,6 +6,7 @@ indent_size = 4
 trim_trailing_whitespace = true
 end_of_line = lf
 insert_final_newline = true
+quote_type = double
 
 # yarn / npm uses 2 spaces when it dumps the file after a change
 [package.json]

.github/ISSUE_TEMPLATE/bug-report.md

@@ -1,20 +1,21 @@
 ---
 name: Bug report
 about: Report an issue
-labels: 
-
+labels:
 ---
 
 <!--
 If you have a problem with a specific rule, please begin your issue title with [rulename] to make it easier to search for.
-I.e. "[no-unused-vars] False positive when fooing the bar" 
+I.e. "[no-unused-vars] False positive when fooing the bar"
 -->
 
 **Repro**
+
 <!--
 Include a minimal reproduction case.
 Please try to avoid code that isn't directly related to the bug, as it makes it harder to investigate.
 -->
+
 ```JSON
 {
   "rules": {
@@ -27,16 +28,12 @@ Please try to avoid code that isn't directly related to the bug, as it makes it
 // your repro code case
 ```
 
-
 **Expected Result**
 
-
 **Actual Result**
 
-
 **Additional Info**
 
-
 **Versions**
 
 | package                    | version |

.github/ISSUE_TEMPLATE/feature_request.md

@@ -1,14 +1,14 @@
 ---
 name: Feature request
 about: Suggest an idea for this project
-labels: 
-
+labels:
 ---
 
 I'd like to propose a **new rule / change to an existing rule**.
 
 **Description**
-<!-- 
+
+<!--
 A clear and concise description of what you would like implemented.
 Code samples can help immensely in describing painting a picture.
 -->

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,11 +1,13 @@
 <!-- Before opening a pull request, either check (`[ ]` → `[x]`) or remove each of these entries) -->
 
 <!-- If adding a rule -->
-- [ ] I’ve filled out the documentation, including all relevant sections and a link to the equivalent TSLint rule if available.
-- [ ] I’ve filled out the rule’s category
-- [ ] I’ve added documentation for the equivalent TSLint rule (in `extraDescription`)
-- [ ] I’ve added the rule documentation link via the helper from `../utils`.
-- [ ] I’ve added the rule to the [roadmap](https://github.com/bradzacher/eslint-plugin-typescript/blob/master/ROADMAP.md)
+
+-   [ ] I’ve filled out the documentation, including all relevant sections and a link to the equivalent TSLint rule if available.
+-   [ ] I’ve filled out the rule’s category
+-   [ ] I’ve added documentation for the equivalent TSLint rule (in `extraDescription`)
+-   [ ] I’ve added the rule documentation link via the helper from `../utils`.
+-   [ ] I’ve added the rule to the [roadmap](https://github.com/bradzacher/eslint-plugin-typescript/blob/master/ROADMAP.md)
 
 <!-- All PRs that change code -->
-- [ ] I’ve added tests for my changes
+
+-   [ ] I’ve added tests for my changes

.prettierrc.yml

@@ -0,0 +1,2 @@
+jsxBracketSameLine: true
+trailingComma: es5

.travis.yml

@@ -1,13 +1,13 @@
 language: node_js
 sudo: false
 node_js:
-    - "6"
-    - "8"
-    - "10"
-    - "11"
+  - "6"
+  - "8"
+  - "10"
+  - "11"
 install: yarn
 script:
-    - yarn lint
-    - yarn format-check
-    - yarn docs:check
-    - yarn test
+  - yarn lint
+  - yarn format-check
+  - yarn docs:check
+  - yarn test

.vscode/extensions.json

@@ -4,8 +4,5 @@
         "dbaeumer.vscode-eslint",
         "editorconfig.editorconfig"
     ],
-    "unwantedRecommendations": [
-        "hookyqr.beautify",
-        "dbaeumer.jshint"
-    ]
+    "unwantedRecommendations": ["hookyqr.beautify", "dbaeumer.jshint"]
 }

.vscode/settings.json

@@ -1,9 +1,6 @@
 {
     // An array of languages where Emmet abbreviations should not be expanded.
-    "emmet.excludeLanguages": [
-        "markdown",
-        "typescript"
-    ],
+    "emmet.excludeLanguages": ["markdown", "typescript"],
 
     // An array of language ids which should be validated by ESLint
     "eslint.validate": [
@@ -31,5 +28,5 @@
     "typescript.preferences.importModuleSpecifier": "auto",
     "javascript.preferences.quoteStyle": "double",
     "typescript.preferences.quoteStyle": "double",
-    "typescript.updateImportsOnFileMove.enabled": "always",
+    "typescript.updateImportsOnFileMove.enabled": "always"
 }

CONTRIBUTING.md

@@ -2,21 +2,21 @@
 
 ## Commenting and Discussing
 
-***Don't be a douche.***
+**_Don't be a douche._**
 Consider the following when commenting:
 
-- Everyone is a human (except for the bots).
-- Everyone is freely providing their time for this project.
-- Everyone wants to build the best tool.
+-   Everyone is a human (except for the bots).
+-   Everyone is freely providing their time for this project.
+-   Everyone wants to build the best tool.
 
 ## PR Requirements
 
 For a PR to be merged, you must pass the following checks:
 
-- there must be no lint errors - `yarn lint`
-- the code must be formatted - `yarn format`
-- your documentation must be up to date - `yarn docs-check`
-- all tests must pass - `yarn test`
+-   there must be no lint errors - `yarn lint`
+-   the code must be formatted - `yarn format`
+-   your documentation must be up to date - `yarn docs-check`
+-   all tests must pass - `yarn test`
 
 There is a commit hook which will help you follow this.
 Travis will also automatically run these checks when you submit your PR (and will block us merging until you fix it).
@@ -25,22 +25,22 @@ Travis will also automatically run these checks when you submit your PR (and wil
 
 When adding or changing a rule, you must:
 
-- Ensure your feature / bug has an issue behind it.
-  - This just makes it easier for people to find information in future, because PRs aren't included in the default issue search.
-- Ensure your changes are covered by tests.
-  - There's no hard and fast rule for how much testing is required, but try to cover as many bases as you can.
-- Ensure your changes are documented in the `docs` folder. We're working to standardise how we document rules, but your docs should:
-  - describe what the rule does, and why you might enable it.
-  - (if any) outline the settings; how to configure them and what each one does
-  - have clear examples of valid and invalid code when using the rule. Bonus points for extra cases showing what each setting does.
+-   Ensure your feature / bug has an issue behind it.
+    -   This just makes it easier for people to find information in future, because PRs aren't included in the default issue search.
+-   Ensure your changes are covered by tests.
+    -   There's no hard and fast rule for how much testing is required, but try to cover as many bases as you can.
+-   Ensure your changes are documented in the `docs` folder. We're working to standardise how we document rules, but your docs should:
+    -   describe what the rule does, and why you might enable it.
+    -   (if any) outline the settings; how to configure them and what each one does
+    -   have clear examples of valid and invalid code when using the rule. Bonus points for extra cases showing what each setting does.
 
 When adding a rule, you must also add a link to the rule in the README.md.
 
 ## Submitting Issues
 
-- If your issue relates to a rule, start your title with the rule name:
-  - `[no-unused-vars] False positive when fooing the bar`
-- Search for the issue before you ask; we try hard to ensure it's easy to find existing issues.
-- Follow the template.
-  - We've built it to reduce the chance of us going back to ask you for things.
-  - Don't be lazy and skip parts of it; we'll just ask you for that information anyway, so it'll only delay the process.
+-   If your issue relates to a rule, start your title with the rule name:
+    -   `[no-unused-vars] False positive when fooing the bar`
+-   Search for the issue before you ask; we try hard to ensure it's easy to find existing issues.
+-   Follow the template.
+    -   We've built it to reduce the chance of us going back to ask you for things.
+    -   Don't be lazy and skip parts of it; we'll just ask you for that information anyway, so it'll only delay the process.

docs/rules/adjacent-overload-signatures.md

@@ -17,24 +17,24 @@ declare namespace Foo {
 }
 
 type Foo = {
-  foo(s: string): void;
-  foo(n: number): void;
-  bar(): void;
-  foo(sn: string | number): void;
-}
+    foo(s: string): void;
+    foo(n: number): void;
+    bar(): void;
+    foo(sn: string | number): void;
+};
 
 interface Foo {
-  foo(s: string): void;
-  foo(n: number): void;
-  bar(): void;
-  foo(sn: string | number): void;
+    foo(s: string): void;
+    foo(n: number): void;
+    bar(): void;
+    foo(sn: string | number): void;
 }
 
 class Foo {
-  foo(s: string): void;
-  foo(n: number): void;
-  bar(): void {}
-  foo(sn: string | number): void {}
+    foo(s: string): void;
+    foo(n: number): void;
+    bar(): void {}
+    foo(sn: string | number): void {}
 }
 
 export function foo(s: string): void;
@@ -54,24 +54,24 @@ declare namespace Foo {
 }
 
 type Foo = {
-  foo(s: string): void;
-  foo(n: number): void;
-  foo(sn: string | number): void;
-  bar(): void;
-}
+    foo(s: string): void;
+    foo(n: number): void;
+    foo(sn: string | number): void;
+    bar(): void;
+};
 
 interface Foo {
-  foo(s: string): void;
-  foo(n: number): void;
-  foo(sn: string | number): void;
-  bar(): void;
+    foo(s: string): void;
+    foo(n: number): void;
+    foo(sn: string | number): void;
+    bar(): void;
 }
 
 class Foo {
-  foo(s: string): void;
-  foo(n: number): void;
-  foo(sn: string | number): void {}
-  bar(): void {}
+    foo(s: string): void;
+    foo(n: number): void;
+    foo(sn: string | number): void {}
+    bar(): void {}
 }
 
 export function bar(): void;
@@ -86,4 +86,4 @@ If you don't care about the general structure of the code, then you will not nee
 
 ## Compatibility
 
-* TSLint: [adjacent-overload-signatures](https://palantir.github.io/tslint/rules/adjacent-overload-signatures/)
+-   TSLint: [adjacent-overload-signatures](https://palantir.github.io/tslint/rules/adjacent-overload-signatures/)

docs/rules/array-type.md

@@ -1,11 +1,12 @@
 # Requires using either `T[]` or `Array<T>` for arrays (array-type)
 
 ```ts
-class Foo<T = Array<Array<Bar>>> extends Bar<T, Array<T>> implements Baz<Array<T>> {
-    private s: Array<T>
+class Foo<T = Array<Array<Bar>>> extends Bar<T, Array<T>>
+    implements Baz<Array<T>> {
+    private s: Array<T>;
 
-    constructor (p: Array<T>) {
-        return new Array()
+    constructor(p: Array<T>) {
+        return new Array();
     }
 }
 ```
@@ -24,10 +25,10 @@ Default config:
 }
 ```
 
-- `array` enforces use of `T[]` for all types `T`.
-- `generic` enforces use of `Array<T>` for all types `T`.
-- `array-simple` enforces use of `T[]` if `T` is a simple type.
+-   `array` enforces use of `T[]` for all types `T`.
+-   `generic` enforces use of `Array<T>` for all types `T`.
+-   `array-simple` enforces use of `T[]` if `T` is a simple type.
 
 ## Related to
 
-* TSLint: [array-type](https://palantir.github.io/tslint/rules/array-type/)
+-   TSLint: [array-type](https://palantir.github.io/tslint/rules/array-type/)