[Docs] Add markdownlint

Author: bmish

.markdownlint.json

@@ -0,0 +1,10 @@
+{
+  "line-length": false,
+  "ul-indent": {
+    "start_indent": 1,
+    "start_indented": true
+  },
+  "ul-style": {
+    "style": "dash"
+  }
+}

.markdownlintignore

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

CONTRIBUTING.md

@@ -6,26 +6,26 @@ Thanks for your interest in helping out! Here are a **few** _weird_ tricks to ~~
 
 When opening an [issue](#issues):
 
-- [ ] search open/closed issues
-- [ ] discuss bug/enhancement in new or old issue
+ - [ ] search open/closed issues
+ - [ ] discuss bug/enhancement in new or old issue
 
 [PR](#prs) time:
 
-- [ ] write tests
-- [ ] implement feature/fix bug
-- [ ] update docs
-- [ ] make a note in change log
+ - [ ] write tests
+ - [ ] implement feature/fix bug
+ - [ ] update docs
+ - [ ] make a note in change log
 
 Remember, you don't need to do it all yourself; any of these are helpful! 😎
 
 ## How to get started
 
 If you are new to `eslint`, below are a few resources that will help you to familiarize yourself with the project.
 
-- Watch [this presentation](https://www.youtube.com/watch?v=2W9tUnALrLg) to learn the fundamental concept of Abstract Syntax Trees (AST) and the way `eslint` works under the hood.
-- Familiarize yourself with the [AST explorer](https://astexplorer.net/) tool. Look into rules in `docs/rules`, create patterns in the rules, then analyze its AST.
-- Explore the blog posts on how to create a custom rule. [One blog post](https://blog.yonatan.dev/writing-a-custom-eslint-rule-to-spot-undeclared-props/). [Second blog post](https://betterprogramming.pub/creating-custom-eslint-rules-cdc579694608).
-- Read the official `eslint` [developer guide](https://eslint.org/docs/latest/developer-guide/architecture/).
+ - Watch [this presentation](https://www.youtube.com/watch?v=2W9tUnALrLg) to learn the fundamental concept of Abstract Syntax Trees (AST) and the way `eslint` works under the hood.
+ - Familiarize yourself with the [AST explorer](https://astexplorer.net/) tool. Look into rules in `docs/rules`, create patterns in the rules, then analyze its AST.
+ - Explore the blog posts on how to create a custom rule. [One blog post](https://blog.yonatan.dev/writing-a-custom-eslint-rule-to-spot-undeclared-props/). [Second blog post](https://betterprogramming.pub/creating-custom-eslint-rules-cdc579694608).
+ - Read the official `eslint` [developer guide](https://eslint.org/docs/latest/developer-guide/architecture/).
 
 ## Issues
 

README.md

@@ -131,7 +131,7 @@ rules:
   # etc...
 ```
 
-# TypeScript
+## TypeScript
 
 You may use the following snippet or assemble your own config using the granular settings described below it.
 
@@ -154,7 +154,7 @@ settings:
 [`@typescript-eslint/parser`]: https://github.com/typescript-eslint/typescript-eslint/tree/HEAD/packages/parser
 [`eslint-import-resolver-typescript`]: https://github.com/import-js/eslint-import-resolver-typescript
 
-# Resolvers
+## Resolvers
 
 With the advent of module bundlers and the current state of modules and module
 syntax specs, it's not always obvious where `import x from 'module'` should look
@@ -175,7 +175,7 @@ resolvers are just npm packages, so [third party packages are supported](https:/
 
 You can reference resolvers in several ways (in order of precedence):
 
-- as a conventional `eslint-import-resolver` name, like `eslint-import-resolver-foo`:
+ - as a conventional `eslint-import-resolver` name, like `eslint-import-resolver-foo`:
 
 ```yaml
 # .eslintrc.yml
@@ -195,7 +195,7 @@ module.exports = {
 }
 ```
 
-- with a full npm module name, like `my-awesome-npm-module`:
+ - with a full npm module name, like `my-awesome-npm-module`:
 
 ```yaml
 # .eslintrc.yml
@@ -214,7 +214,7 @@ module.exports = {
 }
 ```
 
-- with a filesystem path to resolver, defined in this example as a `computed property` name:
+ - with a filesystem path to resolver, defined in this example as a `computed property` name:
 
 ```js
 // .eslintrc.js
@@ -336,11 +336,11 @@ If you are using `yarn` PnP as your package manager, add the `.yarn` folder and
 
 Each item in this array is either a folder's name, its subpath, or its absolute prefix path:
 
-- `jspm_modules` will match any file or folder named `jspm_modules` or which has a direct or non-direct parent named `jspm_modules`, e.g. `/home/me/project/jspm_modules` or `/home/me/project/jspm_modules/some-pkg/index.js`.
+ - `jspm_modules` will match any file or folder named `jspm_modules` or which has a direct or non-direct parent named `jspm_modules`, e.g. `/home/me/project/jspm_modules` or `/home/me/project/jspm_modules/some-pkg/index.js`.
 
-- `packages/core` will match any path that contains these two segments, for example `/home/me/project/packages/core/src/utils.js`.
+ - `packages/core` will match any path that contains these two segments, for example `/home/me/project/packages/core/src/utils.js`.
 
-- `/home/me/project/packages` will only match files and directories inside this directory, and the directory itself.
+ - `/home/me/project/packages` will only match files and directories inside this directory, and the directory itself.
 
 Please note that incomplete names are not allowed here so `components` won't match `bower_components` and `packages/ui` won't match `packages/ui-utils` (but will match `packages/ui/utils`).
 

docs/rules/consistent-type-specifier-style.md

@@ -37,8 +37,8 @@ This rule includes a fixer that will automatically convert your specifiers to th
 
 The rule accepts a single string option which may be one of:
 
-- `'prefer-inline'` - enforces that named type-only specifiers are only ever written with an inline marker; and never as part of a top-level, type-only import.
-- `'prefer-top-level'` - enforces that named type-only specifiers only ever written as part of a top-level, type-only import; and never with an inline marker.
+ - `'prefer-inline'` - enforces that named type-only specifiers are only ever written with an inline marker; and never as part of a top-level, type-only import.
+ - `'prefer-top-level'` - enforces that named type-only specifiers only ever written as part of a top-level, type-only import; and never with an inline marker.
 
 By default the rule will use the `prefer-inline` option.
 

docs/rules/default.md

@@ -19,7 +19,6 @@ A module path that is [ignored] or not [unambiguously an ES module] will not be
 [ignored]: ../README.md#importignore
 [unambiguously an ES module]: https://github.com/bmeck/UnambiguousJavaScriptGrammar
 
-
 ## Rule Details
 
 Given:
@@ -54,7 +53,6 @@ import bar from './bar' // no default export found in ./bar
 import baz from './baz' // no default export found in ./baz
 ```
 
-
 ## When Not To Use It
 
 If you are using CommonJS and/or modifying the exported namespace of any module at
@@ -65,10 +63,9 @@ either, so such a situation will be reported in the importing module.
 
 ## Further Reading
 
-- Lee Byron's [ES7] export proposal
-- [`import/ignore`] setting
-- [`jsnext:main`] (Rollup)
-
+ - Lee Byron's [ES7] export proposal
+ - [`import/ignore`] setting
+ - [`jsnext:main`] (Rollup)
 
 [ES7]: https://github.com/leebyron/ecmascript-more-export-from
 [`import/ignore`]: ../../README.md#importignore

docs/rules/dynamic-import-chunkname.md

@@ -7,8 +7,10 @@ This rule reports any dynamic imports without a webpackChunkName specified in a
 This rule enforces naming of webpack chunks in dynamic imports. When you don't explicitly name chunks, webpack will autogenerate chunk names that are not consistent across builds, which prevents long-term browser caching.
 
 ## Rule Details
+
 This rule runs against `import()` by default, but can be configured to also run against an alternative dynamic-import function, e.g. 'dynamicImport.'
 You can also configure the regex format you'd like to accept for the webpackChunkName - for example, if we don't want the number 6 to show up in our chunk names:
+
  ```javascript
 {
   "dynamic-import-chunkname": [2, {
@@ -19,6 +21,7 @@ You can also configure the regex format you'd like to accept for the webpackChun
 ```
 
 ### invalid
+
 The following patterns are invalid:
 
 ```javascript
@@ -53,7 +56,9 @@ import(
   'someModule',
 );
 ```
+
 ### valid
+
 The following patterns are valid:
 
 ```javascript

docs/rules/export.md

@@ -17,6 +17,7 @@ export default makeClass // Multiple default exports.
 ```
 
 or
+
 ```js
 export const foo = function () { /*...*/ } // Multiple exports of name 'foo'.
 
@@ -31,6 +32,6 @@ intent to rename, etc.
 
 ## Further Reading
 
-- Lee Byron's [ES7] export proposal
+ - Lee Byron's [ES7] export proposal
 
 [ES7]: https://github.com/leebyron/ecmascript-more-export-from

docs/rules/exports-last.md

@@ -4,7 +4,6 @@
 
 This rule enforces that all exports are declared at the bottom of the file. This rule will report any export declarations that comes before any non-export statements.
 
-
 ## This will be reported
 
 ```JS
@@ -45,7 +44,7 @@ export const str = 'foo'
 
 If you don't mind exports being sprinkled throughout a file, you may not want to enable this rule.
 
-#### ES6 exports only
+### ES6 exports only
 
 The exports-last rule is currently only working on ES6 exports. You may not want to enable this rule if you're using CommonJS exports.
 

docs/rules/extensions.md

@@ -10,13 +10,13 @@ In order to provide a consistent use of file extensions across your code base, t
 
 This rule either takes one string option, one object option, or a string and an object option. If it is the string `"never"` (the default value), then the rule forbids the use for any extension. If it is the string `"always"`, then the rule enforces the use of extensions for all import statements. If it is the string `"ignorePackages"`, then the rule enforces the use of extensions for all import statements except package imports.
 
-```
+```json
 "import/extensions": [<severity>, "never" | "always" | "ignorePackages"]
 ```
 
 By providing an object you can configure each extension separately.
 
-```
+```json
 "import/extensions": [<severity>, {
   <extension>: "never" | "always" | "ignorePackages"
 }]
@@ -26,7 +26,7 @@ By providing an object you can configure each extension separately.
 
 By providing both a string and an object, the string will set the default setting for all extensions, and the object can be used to set granular overrides for specific extensions.
 
-```
+```json
 "import/extensions": [
   <severity>,
   "never" | "always" | "ignorePackages",
@@ -40,7 +40,7 @@ For example, `["error", "never", { "svg": "always" }]` would require that all ex
 
 `ignorePackages` can be set as a separate boolean option like this:
 
-```
+```json
 "import/extensions": [
   <severity>,
   "never" | "always" | "ignorePackages",
@@ -62,7 +62,7 @@ When disallowing the use of certain extensions this rule makes an exception and
 
 For example, given the following folder structure:
 
-```
+```pt
 ├── foo
 │   ├── bar.js
 │   ├── bar.json

docs/rules/first.md

@@ -57,6 +57,7 @@ Given that, see [#255] for the reasoning.
 ### With Fixer
 
 This rule contains a fixer to reorder in-body import to top, the following criteria applied:
+
 1. Never re-order relative to each other, even if `absolute-first` is set.
 2. If an import creates an identifier, and that identifier is referenced at module level *before* the import itself, that won't be re-ordered.
 
@@ -67,8 +68,8 @@ enable this rule.
 
 ## Further Reading
 
-- [`import/order`]: a major step up from `absolute-first`
-- Issue [#255]
+ - [`import/order`]: a major step up from `absolute-first`
+ - Issue [#255]
 
 [`import/order`]: ./order.md
 [#255]: https://github.com/import-js/eslint-plugin-import/issues/255

docs/rules/group-exports.md

@@ -71,7 +71,6 @@ export {first}
 export type {firstType}
 ```
 
-
 ### Invalid
 
 ```js

docs/rules/max-dependencies.md

@@ -47,6 +47,7 @@ Ignores `type` imports. Type imports are a feature released in TypeScript 3.8, y
 
 Given `{"max": 2, "ignoreTypeImports": true}`:
 
+<!-- markdownlint-disable-next-line MD024 -- duplicate header -->
 ### Fail
 
 ```ts
@@ -55,6 +56,7 @@ import b from './b';
 import c from './c';
 ```
 
+<!-- markdownlint-disable-next-line MD024 -- duplicate header -->
 ### Pass
 
 ```ts

docs/rules/named.md

@@ -18,7 +18,6 @@ A module path that is [ignored] or not [unambiguously an ES module] will not be
 [unambiguously an ES module]: https://github.com/bmeck/UnambiguousJavaScriptGrammar
 [Flow]: https://flow.org/
 
-
 ## Rule Details
 
 Given:
@@ -94,10 +93,9 @@ runtime, you will likely see false positives with this rule.
 
 ## Further Reading
 
-- [`import/ignore`] setting
-- [`jsnext:main`] deprecation
-- [`pkg.module`] (Rollup)
-
+ - [`import/ignore`] setting
+ - [`jsnext:main`] deprecation
+ - [`pkg.module`] (Rollup)
 
 [`jsnext:main`]: https://github.com/jsforum/jsforum/issues/5
 [`pkg.module`]: https://github.com/rollup/rollup/wiki/pkg.module

docs/rules/namespace.md

@@ -30,6 +30,7 @@ redefinition of the namespace in an intermediate scope. Adherence to the ESLint
 For [ES7], reports if an exported namespace would be empty (no names exported from the referenced module.)
 
 Given:
+
 ```js
 // @module ./named-exports
 export const a = 1
@@ -44,7 +45,9 @@ export class ExportedClass { }
 // ES7
 export * as deep from './deep'
 ```
+
 and:
+
 ```js
 // @module ./deep
 export const e = "MC2"
@@ -94,9 +97,9 @@ still can't be statically analyzed any further.
 
 ## Further Reading
 
-- Lee Byron's [ES7] export proposal
-- [`import/ignore`] setting
-- [`jsnext:main`](Rollup)
+ - Lee Byron's [ES7] export proposal
+ - [`import/ignore`] setting
+ - [`jsnext:main`](Rollup)
 
 [ES7]: https://github.com/leebyron/ecmascript-more-export-from
 [`import/ignore`]: ../../README.md#importignore

docs/rules/newline-after-import.md

@@ -9,9 +9,10 @@ Enforces having one or more empty lines after the last top-level import statemen
 ## Rule Details
 
 This rule supports the following options:
-- `count` which sets the number of newlines that are enforced after the last top-level import statement or require call. This option defaults to `1`.
 
-- `considerComments` which enforces the rule on comments after the last import-statement as well when set to true. This option defaults to `false`.
+ - `count` which sets the number of newlines that are enforced after the last top-level import statement or require call. This option defaults to `1`.
+
+ - `considerComments` which enforces the rule on comments after the last import-statement as well when set to true. This option defaults to `false`.
 
 Valid:
 
@@ -103,6 +104,7 @@ const FOO = 'BAR'
 ```
 
 ## Example options usage
+
 ```json
 {
   "rules": {
@@ -111,7 +113,6 @@ const FOO = 'BAR'
 }
 ```
 
-
 ## When Not To Use It
 
 If you like to visually group module imports with its usage, you don't want to use this rule.

docs/rules/no-absolute-path.md

@@ -38,9 +38,9 @@ By default, only ES6 imports and CommonJS `require` calls will have this rule en
 
 You may provide an options object providing true/false for any of
 
-- `esmodule`: defaults to `true`
-- `commonjs`: defaults to `true`
-- `amd`: defaults to `false`
+ - `esmodule`: defaults to `true`
+ - `commonjs`: defaults to `true`
+ - `amd`: defaults to `false`
 
 If `{ amd: true }` is provided, dependency paths for AMD-style `define` and `require`
 calls will be resolved: