docs: add markdownlint (#115)

Author: bmish

.markdownlint.json

@@ -0,0 +1,3 @@
+{
+  "line-length": false
+}

.markdownlintignore

@@ -0,0 +1,3 @@
+CHANGELOG.md
+LICENSE
+node_modules

README.md

@@ -1,4 +1,5 @@
 # eslint-plugin-qunit
+
 ![CI](https://github.com/platinumazure/eslint-plugin-qunit/workflows/CI/badge.svg)
 [![Coverage Status](https://coveralls.io/repos/platinumazure/eslint-plugin-qunit/badge.svg?branch=master&service=github)](https://coveralls.io/github/platinumazure/eslint-plugin-qunit?branch=master)
 [![devDependency Status](https://david-dm.org/platinumazure/eslint-plugin-qunit/dev-status.svg)](https://david-dm.org/platinumazure/eslint-plugin-qunit#info=devDependencies)
@@ -21,8 +22,8 @@ For more details on how to extend your configuration from one or both of these p
 
 Each rule has emojis denoting:
 
-- What configuration it belongs to
-- :wrench: if some problems reported by the rule are automatically fixable by the `--fix` [command line](https://eslint.org/docs/user-guide/command-line-interface#fixing-problems) option
+* What configuration it belongs to
+* :wrench: if some problems reported by the rule are automatically fixable by the `--fix` [command line](https://eslint.org/docs/user-guide/command-line-interface#fixing-problems) option
 
 <!--RULES_TABLE_START-->
 
@@ -101,27 +102,29 @@ Thanks goes to these wonderful people ([emoji key](https://github.com/kentcdodds
 <!-- prettier-ignore-end -->
 <!-- ALL-CONTRIBUTORS-LIST:END -->
 
+<!-- markdownlint-disable line-length -->
+
 This project follows the [all-contributors](https://github.com/kentcdodds/all-contributors) specification. Contributions of any kind welcome!
 
 ## Semantic Versioning Policy
 
 Like ESLint itself, this ESLint plugin follows [semantic versioning](http://semver.org). However, due to the nature of ESLint as a code quality tool, it's not always clear when a minor or major version bump occurs. To help clarify this for everyone, we've defined the following semantic versioning policy, based on the policy used by ESLint:
 
 * Patch release (intended not to break your lint build)
-    * A bug fix in a plugin rule that results in ESLint reporting fewer errors.
-    * Improvements to documentation.
-    * Non-user-facing changes such as refactoring code; adding, deleting, or modifying tests; and increasing test coverage.
-    * Re-releasing after a failed release (i.e., after having published a release that doesn't work for anyone).
+  * A bug fix in a plugin rule that results in ESLint reporting fewer errors.
+  * Improvements to documentation.
+  * Non-user-facing changes such as refactoring code; adding, deleting, or modifying tests; and increasing test coverage.
+  * Re-releasing after a failed release (i.e., after having published a release that doesn't work for anyone).
 * Minor release (might break your lint build)
-    * A bug fix in a rule that results in ESLint reporting more errors.
-    * A new rule is created (without being added to plugin configuration).
-    * A new option to an existing rule is created (without any default options changing).
-    * A new plugin configuration is created.
-    * An existing rule is deprecated.
+  * A bug fix in a rule that results in ESLint reporting more errors.
+  * A new rule is created (without being added to plugin configuration).
+  * A new option to an existing rule is created (without any default options changing).
+  * A new plugin configuration is created.
+  * An existing rule is deprecated.
 * Major release (likely to break your lint build)
-    * An existing plugin configuration is changed in any way, including but not limited to:
-        * A new rule is added to the configuration.
-        * A rule is removed from the configuration.
-        * The options used in configuration for a rule are changed
-    * An existing rule is removed.
-    * A backward-incompatible change is made to the options of a rule.
+  * An existing plugin configuration is changed in any way, including but not limited to:
+    * A new rule is added to the configuration.
+    * A rule is removed from the configuration.
+    * The options used in configuration for a rule are changed
+  * An existing rule is removed.
+  * A backward-incompatible change is made to the options of a rule.

docs/rules/assert-args.md

@@ -16,7 +16,7 @@ We can apply the same analysis to all of QUnit's assertions. In general,
 optional message; and the other assertions expect two arguments and one optional
 message.
 
-# Rule Details
+## Rule Details
 
 The following patterns are considered warnings:
 
@@ -148,15 +148,15 @@ assert.notPropEqual(result, expected, 'message');
 
 ```
 
-# Known Limitations
+## Known Limitations
 
 At this point, there is no special validation for assertion message arguments.
 We eventually want to add support for different types of validation for
 assertion message arguments (for example, requiring that assertion messages be
 string literals). However, we learned early on that enforcing string literal
 assertion messages makes the rule nearly unusable in some codebases.
 
-# When Not to Use It
+## When Not to Use It
 
 This rule should be reasonably safe to use in all circumstances.
 

docs/rules/literal-compare-order.md

@@ -20,7 +20,7 @@ regarded as "expected" values, rather than actual values, and then flags
 assertions in which the literal/"expected" value is known to be in the argument
 slot reserved for the "actual" value.
 
-# Rule Details
+## Rule Details
 
 The following patterns are considered warnings:
 
@@ -98,7 +98,7 @@ assert.notPropEqual(variable, "Literal", "message");
 
 ```
 
-# When Not to Use It
+## When Not to Use It
 
 This rule can be disabled if you aren't concerned about the readability of test
 reports.

docs/rules/no-assert-ok.md

@@ -3,11 +3,13 @@
 `assert.ok` and `assert.notOk` pass for any truthy/falsy argument. As [many expressions evaluate to true/false in JavaScript](https://developer.mozilla.org/en-US/docs/Glossary/Truthy) the usage of `assert.ok` is potentially error prone. In general, it should be advisable to always test for exact values in tests which makes tests a lot more solid.
 
 An example when using `assert.ok` can involuntarily go wrong:
-```
+
+```js
 test('test myFunc returns a truthy value' (assert) => {
   assert.ok(myFunc);
 });
 ```
+
 Here by mistake a developer just passed to `assert.ok` a pointer to `myFunc` instead of explicitly calling it. This test is going pass no matter how `myFunc` changes. Using `assert.strictEqual(myFunc, theReturnValue)` solves the problem as this becomes an explicit check for equality.
 
 ## Rule Details

docs/rules/no-loose-assertions.md

@@ -5,16 +5,19 @@ The `assert.equal`/`assert.notEqual` assertion methods in QUnit use loose equali
 `assert.ok` and `assert.notOk` pass for any truthy/falsy argument. As [many expressions evaluate to true/false in JavaScript](https://developer.mozilla.org/en-US/docs/Glossary/Truthy) the usage of `assert.ok` is potentially error prone. In general, it should be advisable to always test for exact values in tests which makes tests a lot more solid.
 
 An example when using `assert.ok` can involuntarily go wrong:
-```
+
+```js
 test('test myFunc returns a truthy value' (assert) => {
   assert.ok(myFunc);
 });
 ```
+
 Here by mistake a developer just passed to `assert.ok` a pointer to `myFunc` instead of explicitly calling it. This test is going pass no matter how `myFunc` changes. Using `assert.strictEqual(myFunc, theReturnValue)` solves the problem as this becomes an explicit check for equality.
 
 The assertions to lint against can be controlled with an array of assertions (default `["equal", "notEqual", "ok", "notOk"]`).
 
 To fine tune the error message (which by default will recommend to use `strictEqual`, `notStrictEqual`, `deepEqual`, or `propEqual`) a configuration object can be passed as an option instead of a string. The configuration object has two properties:
+
 * `disallowed`: the name of the assertion to disallow (either `equal`, `ok`, or `notOk`);
 * `recommended`: an array of strings representing the recommended options to display as an error message. The strings in the array will be concatenated to build the error message: `Unexpected {{assertVar}}.{{assertion}}. Use {{assertVar}}.<recommended_1>, {{assertVar}}.<recommended_2>.` when using local assertions and `Unexpected {{assertion}}. Use <recommended_1>, <recommended_2>.` when using global assertions.
 

docs/rules/no-nested-tests.md

@@ -49,4 +49,3 @@ It should be safe to use this rule. However it may cause false positive when usi
 
 * [QUnit.module() Nested Scope](https://github.com/qunitjs/qunit/blob/master/docs/QUnit/module.md#nested-scope)
 * [QUnit.test](https://github.com/qunitjs/qunit/blob/master/docs/QUnit/test.md)
-

docs/rules/require-expect.md

@@ -26,9 +26,9 @@ The "never-except-zero" option disallows `except` calls, except when used to
 explicitly assert that a test performs no assertions, which would otherwise
 be considered an error.
 
-# Rule Details
+## Rule Details
 
-## always
+### always
 
 When using the default "always" option, each test needs an expect call. So the
 following would warn.
@@ -53,7 +53,7 @@ test('name', function() {
 });
 ```
 
-## except-simple
+### except-simple
 
 When using the "except-simple" option, the following patterns are considered
 warnings.
@@ -127,7 +127,7 @@ test('name', function(assert) {
 });
 ```
 
-## never
+### never
 
 The following would warn.
 
@@ -152,7 +152,7 @@ test('name', function(assert) {
 });
 ```
 
-## never-except-zero
+### never-except-zero
 
 The following would warn.
 
@@ -177,7 +177,7 @@ test('name', function(assert) {
 });
 ```
 
-# When Not to Use It
+## When Not to Use It
 
 1. If your tests have some logic that relies on an unpredictable number of
    assertions being called.