Merge pull request #306 from ddzz/add-markdownlint

Add `markdownlint` and fix linting issues

.github/workflows/ci.yml

@@ -17,6 +17,8 @@ jobs:
                   node-version: ${{ matrix.node }}
             - name: Install dependencies
               run: npm ci
+            - name: Run linters
+              run: yarn pretest && yarn lint:docs
             - name: Run tests
               run: npm test
               timeout-minutes: 20

.markdownlint.json

@@ -0,0 +1,4 @@
+{
+    "line-length": false,
+    "first-line-h1": false
+  }

.markdownlintignore

@@ -0,0 +1,2 @@
+CHANGELOG.md
+node_modules

docs/rules/handle-done-callback.md

@@ -59,6 +59,7 @@ before(function (done) {
     });
 });
 ```
+
 ## Options
 
 This rule supports the following options:

docs/rules/no-empty-description.md

@@ -42,4 +42,4 @@ Example of a custom rule configuration:
            message: 'custom error message'
        } ]
    }
-```
+```

docs/rules/no-hooks.md

@@ -57,7 +57,6 @@ This rule supports the following options:
 }
 ```
 
-
 ## When Not To Use It
 
 * If you use another library which exposes a similar API as mocha (e.g. `before`, `after`), you should turn this rule off, because it would raise warnings.

docs/rules/no-nested-tests.md

@@ -9,6 +9,7 @@ it('something', function () {
     });
 });
 ```
+
 Something like this could easily happen by accident where the outer test case was actually meant to be a suite instead of a test.
 This rule reports such nested test cases in order to prevent problems where those nested tests are skipped silently.
 

docs/rules/no-synchronous-tests.md

@@ -50,7 +50,7 @@ rules: {
 },
 ```
 
-### Caveats:
+### Caveats
 
 This rule cannot guarantee that a returned function call is actually a promise, it only confirms that the return was made.
 
@@ -65,10 +65,10 @@ it('test name', myTestFn);
 
 ## When Not To Use It
 
-* If you are primarily writing synchronous tests, and rarely need the `done` callback, promise functionality or async functions.
+- If you are primarily writing synchronous tests, and rarely need the `done` callback, promise functionality or async functions.
 
 ## Further Reading
 
-* [Synchronous Code](http://mochajs.org/#synchronous-code)
-* [Asynchronous Code](http://mochajs.org/#asynchronous-code)
-* [Working with Promises](http://mochajs.org/#working-with-promises)
+- [Synchronous Code](http://mochajs.org/#synchronous-code)
+- [Asynchronous Code](http://mochajs.org/#asynchronous-code)
+- [Working with Promises](http://mochajs.org/#working-with-promises)

docs/rules/valid-suite-description.md

@@ -17,8 +17,8 @@ rules: {
 
 where:
 
- * `warn` is a rule error level (see [Configuring Rules](http://eslint.org/docs/user-guide/configuring#configuring-rules))
- * `^[A-Z]` is a custom regular expression pattern to match suite names against; `^[A-Z]` enforces a suite name to start with an upper-case letter
+* `warn` is a rule error level (see [Configuring Rules](http://eslint.org/docs/user-guide/configuring#configuring-rules))
+* `^[A-Z]` is a custom regular expression pattern to match suite names against; `^[A-Z]` enforces a suite name to start with an upper-case letter
 
 The following patterns are considered warnings (with the example rule configuration posted above):
 

docs/rules/valid-test-description.md

@@ -23,10 +23,10 @@ Example of a custom rule configuration:
 
 where:
 
- * `warn` is a rule error level (see [Configuring Rules](http://eslint.org/docs/user-guide/configuring#configuring-rules))
- * `mypattern$` is a custom regular expression pattern to match test names against
- * `["it", "specify", "test", "mytestname"]` is an array of custom test names
- * `custom error message` a custom error message to describe your pattern
+* `warn` is a rule error level (see [Configuring Rules](http://eslint.org/docs/user-guide/configuring#configuring-rules))
+* `mypattern$` is a custom regular expression pattern to match test names against
+* `["it", "specify", "test", "mytestname"]` is an array of custom test names
+* `custom error message` a custom error message to describe your pattern
 
 The following patterns are considered warnings (with the default rule configuration):