Update checked-in dependencies

node_modules/eslint-plugin-import/CHANGELOG.md

@@ -6,6 +6,14 @@ This change log adheres to standards from [Keep a CHANGELOG](https://keepachange
 
 ## [Unreleased]
 
+## [2.28.1] - 2023-08-18
+
+### Fixed
+- [`order`]: revert breaking change to single nested group ([#2854], thanks [@yndajas])
+
+### Changed
+- [Docs] remove duplicate fixable notices in docs ([#2850], thanks [@bmish])
+
 ## [2.28.0] - 2023-07-27
 
 ### Fixed
@@ -1079,6 +1087,8 @@ for info on changes for earlier releases.
 
 [`memo-parser`]: ./memo-parser/README.md
 
+[#2854]: https://github.com/import-js/eslint-plugin-import/pull/2854
+[#2850]: https://github.com/import-js/eslint-plugin-import/pull/2850
 [#2842]: https://github.com/import-js/eslint-plugin-import/pull/2842
 [#2835]: https://github.com/import-js/eslint-plugin-import/pull/2835
 [#2832]: https://github.com/import-js/eslint-plugin-import/pull/2832
@@ -1537,7 +1547,8 @@ for info on changes for earlier releases.
 [#119]: https://github.com/import-js/eslint-plugin-import/issues/119
 [#89]: https://github.com/import-js/eslint-plugin-import/issues/89
 
-[Unreleased]: https://github.com/import-js/eslint-plugin-import/compare/v2.28.0...HEAD
+[Unreleased]: https://github.com/import-js/eslint-plugin-import/compare/v2.28.1...HEAD
+[2.28.1]: https://github.com/import-js/eslint-plugin-import/compare/v2.28.0...v2.28.1
 [2.28.0]: https://github.com/import-js/eslint-plugin-import/compare/v2.27.5...v2.28.0
 [2.27.5]: https://github.com/import-js/eslint-plugin-import/compare/v2.27.4...v2.27.5
 [2.27.4]: https://github.com/import-js/eslint-plugin-import/compare/v2.27.3...v2.27.4
@@ -1883,5 +1894,6 @@ for info on changes for earlier releases.
 [@wtgtybhertgeghgtwtg]: https://github.com/wtgtybhertgeghgtwtg
 [@xM8WVqaG]: https://github.com/xM8WVqaG
 [@xpl]: https://github.com/xpl
+[@yndajas]: https://github.com/yndajas
 [@yordis]: https://github.com/yordis
 [@zloirock]: https://github.com/zloirock

node_modules/eslint-plugin-import/CONTRIBUTING.md

@@ -6,15 +6,15 @@ 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! 😎
 
@@ -22,10 +22,10 @@ Remember, you don't need to do it all yourself; any of these are helpful! 😎
 
 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
 

node_modules/eslint-plugin-import/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`).
 

node_modules/eslint-plugin-import/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.
 

node_modules/eslint-plugin-import/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

node_modules/eslint-plugin-import/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

node_modules/eslint-plugin-import/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

node_modules/eslint-plugin-import/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.
 

node_modules/eslint-plugin-import/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

node_modules/eslint-plugin-import/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

node_modules/eslint-plugin-import/docs/rules/group-exports.md

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

node_modules/eslint-plugin-import/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

node_modules/eslint-plugin-import/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

node_modules/eslint-plugin-import/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

node_modules/eslint-plugin-import/docs/rules/newline-after-import.md

@@ -5,14 +5,14 @@
 <!-- end auto-generated rule header -->
 
 Enforces having one or more empty lines after the last top-level import statement or require call.
-+(fixable) The `--fix` option on the [command line] automatically fixes problems reported by this rule.
 
 ## 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`.
+This rule supports the following options:
 
-- `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:
 
@@ -104,6 +104,7 @@ const FOO = 'BAR'
 ```
 
 ## Example options usage
+
 ```json
 {
   "rules": {
@@ -112,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.

node_modules/eslint-plugin-import/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:

node_modules/eslint-plugin-import/docs/rules/no-amd.md

@@ -33,5 +33,5 @@ Special thanks to @xjamundx for donating his no-define rule as a start to this.
 
 ## Further Reading
 
-- [`no-commonjs`](./no-commonjs.md): report CommonJS `require` and `exports`
-- Source: https://github.com/xjamundx/eslint-plugin-modules
+ - [`no-commonjs`](./no-commonjs.md): report CommonJS `require` and `exports`
+ - Source: <https://github.com/xjamundx/eslint-plugin-modules>

node_modules/eslint-plugin-import/docs/rules/no-anonymous-default-export.md

@@ -28,6 +28,7 @@ The complete default configuration looks like this.
 ## Rule Details
 
 ### Fail
+
 ```js
 export default []
 
@@ -48,6 +49,7 @@ export default new Foo()
 ```
 
 ### Pass
+
 ```js
 const foo = 123
 export default foo

node_modules/eslint-plugin-import/docs/rules/no-commonjs.md

@@ -86,12 +86,11 @@ don't want this rule.
 It is also fairly noisy if you have a larger codebase that is being transitioned
 from CommonJS to ES6 modules.
 
-
 ## Contributors
 
 Special thanks to @xjamundx for donating the module.exports and exports.* bits.
 
 ## Further Reading
 
-- [`no-amd`](./no-amd.md): report on AMD `require`, `define`
-- Source: https://github.com/xjamundx/eslint-plugin-modules
+ - [`no-amd`](./no-amd.md): report on AMD `require`, `define`
+ - Source: <https://github.com/xjamundx/eslint-plugin-modules>

node_modules/eslint-plugin-import/docs/rules/no-cycle.md

@@ -24,7 +24,6 @@ for that, see [`no-self-import`].
 
 This rule ignores type-only imports in Flow and TypeScript syntax (`import type` and `import typeof`), which have no runtime effect.
 
-
 ## Rule Details
 
 ### Options
@@ -103,9 +102,9 @@ this rule enabled.
 
 ## Further Reading
 
-- [Original inspiring issue](https://github.com/import-js/eslint-plugin-import/issues/941)
-- Rule to detect that module imports itself: [`no-self-import`]
-- [`import/external-module-folders`] setting
+ - [Original inspiring issue](https://github.com/import-js/eslint-plugin-import/issues/941)
+ - Rule to detect that module imports itself: [`no-self-import`]
+ - [`import/external-module-folders`] setting
 
 [`no-self-import`]: ./no-self-import.md
 

node_modules/eslint-plugin-import/docs/rules/no-deprecated.md

@@ -3,7 +3,7 @@
 <!-- end auto-generated rule header -->
 
 Reports use of a deprecated name, as indicated by a JSDoc block with a `@deprecated`
-tag or TomDoc `Deprecated: ` comment.
+tag or TomDoc `Deprecated:` comment.
 
 using a JSDoc `@deprecated` tag:
 
@@ -45,19 +45,18 @@ export function multiply(six, nine) {
 Only JSDoc is enabled by default. Other documentation styles can be enabled with
 the `import/docstyle` setting.
 
-
 ```yaml
 # .eslintrc.yml
 settings:
   import/docstyle: ['jsdoc', 'tomdoc']
 ```
 
-### Worklist
+## Worklist
 
-- [x] report explicit imports on the import node
-- [x] support namespaces
-  - [x] should bubble up through deep namespaces (#157)
-- [x] report explicit imports at reference time (at the identifier) similar to namespace
-- [x] mark module deprecated if file JSDoc has a @deprecated tag?
-- [ ] don't flag redeclaration of imported, deprecated names
-- [ ] flag destructuring
+ - [x] report explicit imports on the import node
+ - [x] support namespaces
+   - [x] should bubble up through deep namespaces (#157)
+ - [x] report explicit imports at reference time (at the identifier) similar to namespace
+ - [x] mark module deprecated if file JSDoc has a @deprecated tag?
+ - [ ] don't flag redeclaration of imported, deprecated names
+ - [ ] flag destructuring

node_modules/eslint-plugin-import/docs/rules/no-duplicates.md

@@ -7,7 +7,6 @@
 <!-- end auto-generated rule header -->
 
 Reports if a resolved path is imported more than once.
-+(fixable) The `--fix` option on the [command line] automatically fixes some problems reported by this rule.
 
 ESLint core has a similar rule ([`no-duplicate-imports`](https://eslint.org/docs/rules/no-duplicate-imports)), but this version
 is different in two key ways:
@@ -18,6 +17,7 @@ is different in two key ways:
 ## Rule Details
 
 Valid:
+
 ```js
 import SomeDefaultClass, * as names from './mod'
 // Flow `type` import from same module is fine
@@ -53,6 +53,7 @@ Config:
 ```
 
 And then the following code becomes valid:
+
 ```js
 import minifiedMod from './mod?minify'
 import noCommentsMod from './mod?comments=0'
@@ -60,6 +61,7 @@ import originalMod from './mod'
 ```
 
 It will still catch duplicates when using the same module and the exact same query string:
+
 ```js
 import SomeDefaultClass from './mod?minify'
 

node_modules/eslint-plugin-import/docs/rules/no-empty-named-blocks.md

@@ -9,35 +9,41 @@ Reports the use of empty named import blocks.
 ## Rule Details
 
 ### Valid
+
 ```js
 import { mod } from 'mod'
 import Default, { mod } from 'mod'
 ```
 
 When using typescript
+
 ```js
 import type { mod } from 'mod'
 ```
 
 When using flow
+
 ```js
 import typeof { mod } from 'mod'
 ```
 
 ### Invalid
+
 ```js
 import {} from 'mod'
 import Default, {} from 'mod'
 ```
 
 When using typescript
+
 ```js
 import type Default, {} from 'mod'
 import type {} from 'mod'
 ```
 
 When using flow
+
 ```js
 import typeof {} from 'mod'
 import typeof Default, {} from 'mod'
-```
+```

node_modules/eslint-plugin-import/docs/rules/no-extraneous-dependencies.md

@@ -7,7 +7,7 @@ The closest parent `package.json` will be used. If no `package.json` is found, t
 
 Modules have to be installed for this rule to work.
 
-### Options
+## Options
 
 This rule supports the following options:
 
@@ -60,6 +60,7 @@ folder layouts:
 ## Rule Details
 
 Given the following `package.json`:
+
 ```json
 {
   "name": "my-project",
@@ -88,7 +89,6 @@ Given the following `package.json`:
 }
 ```
 
-
 ## Fail
 
 ```js
@@ -117,7 +117,6 @@ var foo = require('./foo');
 import type { MyType } from 'foo';
 ```
 
-
 ## Pass
 
 ```js
@@ -135,7 +134,6 @@ import type { MyType } from 'foo';
 import react from 'react';
 ```
 
-
 ## When Not To Use It
 
 If you do not have a `package.json` file in your project.

node_modules/eslint-plugin-import/docs/rules/no-import-module-exports.md

@@ -12,7 +12,8 @@ If you have multiple entry points or are using `js:next` this rule includes an
 
 ## Options
 
-#### `exceptions`
+### `exceptions`
+
  - An array of globs. The rule will be omitted from any file that matches a glob
    in the options array. For example, the following setting will omit the rule
    in the `some-file.js` file.
@@ -43,6 +44,7 @@ console.log(baz)
 ```
 
 ### Pass
+
 Given the following package.json:
 
 ```json
@@ -75,4 +77,5 @@ module.exports = foo;
 ```
 
 ### Further Reading
+
  - [webpack issue #4039](https://github.com/webpack/webpack/issues/4039)

node_modules/eslint-plugin-import/docs/rules/no-internal-modules.md

@@ -8,14 +8,14 @@ Use this rule to prevent importing the submodules of other modules.
 
 This rule has two mutally exclusive options that are arrays of [minimatch/glob patterns](https://github.com/isaacs/node-glob#glob-primer) patterns:
 
-- `allow` that include paths and import statements that can be imported with reaching.
-- `forbid` that exclude paths and import statements that can be imported with reaching.
+ - `allow` that include paths and import statements that can be imported with reaching.
+ - `forbid` that exclude paths and import statements that can be imported with reaching.
 
 ### Examples
 
 Given the following folder structure:
 
-```
+```pt
 my-project
 ├── actions
 │   └── getUser.js
@@ -33,7 +33,8 @@ my-project
 ```
 
 And the .eslintrc file:
-```
+
+```json
 {
   ...
   "rules": {
@@ -76,7 +77,7 @@ export { settings } from '../app';
 
 Given the following folder structure:
 
-```
+```pt
 my-project
 ├── actions
 │   └── getUser.js
@@ -94,7 +95,8 @@ my-project
 ```
 
 And the .eslintrc file:
-```
+
+```json
 {
   ...
   "rules": {

node_modules/eslint-plugin-import/docs/rules/no-mutable-exports.md

@@ -43,8 +43,8 @@ export function getCount() {} // reported here: exported function is reassigned
 To prevent general reassignment of these identifiers, exported or not, you may
 want to enable the following core ESLint rules:
 
-- [no-func-assign]
-- [no-class-assign]
+ - [no-func-assign]
+ - [no-class-assign]
 
 [no-func-assign]: https://eslint.org/docs/rules/no-func-assign
 [no-class-assign]: https://eslint.org/docs/rules/no-class-assign

node_modules/eslint-plugin-import/docs/rules/no-named-as-default-member.md

@@ -17,13 +17,12 @@ Furthermore, [in Babel 5 this is actually how things worked][blog]. This was
 fixed in Babel 6. Before upgrading an existing codebase to Babel 6, it can be
 useful to run this lint rule.
 
-
 [blog]: https://kentcdodds.com/blog/misunderstanding-es6-modules-upgrading-babel-tears-and-a-solution
 
-
 ## Rule Details
 
 Given:
+
 ```js
 // foo.js
 export default 'foo';
@@ -31,11 +30,13 @@ export const bar = 'baz';
 ```
 
 ...this would be valid:
+
 ```js
 import foo, {bar} from './foo.js';
 ```
 
 ...and the following would be reported:
+
 ```js
 // Caution: `foo` also has a named export `bar`.
 // Check if you meant to write `import {bar} from './foo.js'` instead.

node_modules/eslint-plugin-import/docs/rules/no-named-as-default.md

@@ -8,12 +8,13 @@ Reports use of an exported name as the locally imported name of a default export
 
 Rationale: using an exported name as the name of the default export is likely...
 
-- *misleading*: others familiar with `foo.js` probably expect the name to be `foo`
-- *a mistake*: only needed to import `bar` and forgot the brackets (the case that is prompting this)
+ - _misleading_: others familiar with `foo.js` probably expect the name to be `foo`
+ - _a mistake_: only needed to import `bar` and forgot the brackets (the case that is prompting this)
 
 ## Rule Details
 
 Given:
+
 ```js
 // foo.js
 export default 'foo';
@@ -21,11 +22,13 @@ export const bar = 'baz';
 ```
 
 ...this would be valid:
+
 ```js
 import foo from './foo.js';
 ```
 
 ...and this would be reported:
+
 ```js
 // message: Using exported name 'bar' as identifier for default export.
 import bar from './foo.js';
@@ -43,8 +46,8 @@ export bar from './foo.js';
 
 ## Further Reading
 
-- ECMAScript Proposal: [export ns from]
-- ECMAScript Proposal: [export default from]
+ - ECMAScript Proposal: [export ns from]
+ - ECMAScript Proposal: [export default from]
 
 [export ns from]: https://github.com/leebyron/ecmascript-export-ns-from
 [export default from]: https://github.com/leebyron/ecmascript-export-default-from

node_modules/eslint-plugin-import/docs/rules/no-named-default.md

@@ -13,6 +13,7 @@ Note that type imports, as used by [Flow], are always ignored.
 ## Rule Details
 
 Given:
+
 ```js
 // foo.js
 export default 'foo';
@@ -20,12 +21,14 @@ export const bar = 'baz';
 ```
 
 ...these would be valid:
+
 ```js
 import foo from './foo.js';
 import foo, { bar } from './foo.js';
 ```
 
 ...and these would be reported:
+
 ```js
 // message: Using exported name 'bar' as identifier for default export.
 import { default as foo } from './foo.js';

node_modules/eslint-plugin-import/docs/rules/no-namespace.md

@@ -6,14 +6,13 @@
 
 Enforce a convention of not using namespace (a.k.a. "wildcard" `*`) imports.
 
-+(fixable) The `--fix` option on the [command line] automatically fixes problems reported by this rule, provided that the namespace object is only used for direct member access, e.g. `namespace.a`.
-The `--fix` functionality for this rule requires ESLint 5 or newer.
+The rule is auto-fixable when the namespace object is only used for direct member access, e.g. `namespace.a`.
 
-### Options
+## Options
 
 This rule supports the following options:
 
-- `ignore`: array of glob strings for modules that should be ignored by the rule.
+ - `ignore`: array of glob strings for modules that should be ignored by the rule.
 
 ## Rule Details
 

node_modules/eslint-plugin-import/docs/rules/no-nodejs-modules.md

@@ -4,11 +4,11 @@
 
 Forbid the use of Node.js builtin modules. Can be useful for client-side web projects that do not have access to those modules.
 
-### Options
+## Options
 
 This rule supports the following options:
 
-- `allow`: Array of names of allowed modules. Defaults to an empty array.
+ - `allow`: Array of names of allowed modules. Defaults to an empty array.
 
 ## Rule Details
 

node_modules/eslint-plugin-import/docs/rules/no-relative-packages.md

@@ -9,13 +9,11 @@ Use this rule to prevent importing packages through relative paths.
 It's useful in Yarn/Lerna workspaces, were it's possible to import a sibling
 package using `../package` relative path, while direct `package` is the correct one.
 
-+(fixable) The `--fix` option on the [command line] automatically fixes problems reported by this rule.
-
-### Examples
+## Examples
 
 Given the following folder structure:
 
-```
+```pt
 my-project
 ├── packages
 │   ├── foo
@@ -28,7 +26,8 @@ my-project
 ```
 
 And the .eslintrc file:
-```
+
+```json
 {
   ...
   "rules": {

node_modules/eslint-plugin-import/docs/rules/no-relative-parent-imports.md

@@ -8,7 +8,7 @@ This rule is useful for enforcing tree-like folder structures instead of complex
 
 To fix violations of this rule there are three general strategies. Given this example:
 
-```
+```pt
 numbers
 └── three.js
 add.js
@@ -32,51 +32,51 @@ You can,
 
 1. Move the file to be in a sibling folder (or higher) of the dependency.
 
-`three.js` could be be in the same folder as `add.js`:
+   `three.js` could be be in the same folder as `add.js`:
 
-```
-three.js
-add.js
-```
+   ```pt
+   three.js
+   add.js
+   ```
 
-or since `add` doesn't have any imports, it could be in it's own directory (namespace):
+   or since `add` doesn't have any imports, it could be in it's own directory (namespace):
 
-```
-math
-└── add.js
-three.js
-```
+   ```pt
+   math
+   └── add.js
+   three.js
+   ```
 
 2. Pass the dependency as an argument at runtime (dependency injection)
 
-```js
-// three.js
-export default function three(add) {
-  return add([1, 2]);
-}
+   ```js
+   // three.js
+   export default function three(add) {
+     return add([1, 2]);
+   }
 
-// somewhere else when you use `three.js`:
-import add from './add';
-import three from './numbers/three';
-console.log(three(add));
-```
+   // somewhere else when you use `three.js`:
+   import add from './add';
+   import three from './numbers/three';
+   console.log(three(add));
+   ```
 
 3. Make the dependency a package so it's globally available to all files in your project:
 
-```js
-import add from 'add'; // from https://www.npmjs.com/package/add
-export default function three() {
-  return add([1,2]);
-}
-```
+   ```js
+   import add from 'add'; // from https://www.npmjs.com/package/add
+   export default function three() {
+     return add([1,2]);
+   }
+   ```
 
 These are (respectively) static, dynamic & global solutions to graph-like dependency resolution.
 
-### Examples
+## Examples
 
 Given the following folder structure:
 
-```
+```pt
 my-project
 ├── lib
 │   ├── a.js
@@ -85,7 +85,8 @@ my-project
 ```
 
 And the .eslintrc file:
-```
+
+```json
 {
   ...
   "rules": {

node_modules/eslint-plugin-import/docs/rules/no-restricted-paths.md

@@ -13,25 +13,26 @@ This rule has one option. The option is an object containing the definition of a
 The default value for `basePath` is the current working directory.
 
 Each zone consists of the `target` paths, a `from` paths, and an optional `except` and `message` attribute.
-- `target` contains the paths where the restricted imports should be applied. It can be expressed by
-    - directory string path that matches all its containing files
-    - glob pattern matching all the targeted files
-    - an array of multiple of the two types above
-- `from` paths define the folders that are not allowed to be used in an import. It can be expressed by
-    - directory string path that matches all its containing files
-    - glob pattern matching all the files restricted to be imported
-    - an array of multiple directory string path
-    - an array of multiple glob patterns
-- `except` may be defined for a zone, allowing exception paths that would otherwise violate the related `from`. Note that it does not alter the behaviour of `target` in any way.
-    - in case `from` contains only glob patterns, `except` must be an array of glob patterns as well
-    - in case `from` contains only directory path, `except` is relative to `from` and cannot backtrack to a parent directory
-- `message` - will be displayed in case of the rule violation.
+
+ - `target` contains the paths where the restricted imports should be applied. It can be expressed by
+   - directory string path that matches all its containing files
+   - glob pattern matching all the targeted files
+   - an array of multiple of the two types above
+ - `from` paths define the folders that are not allowed to be used in an import. It can be expressed by
+   - directory string path that matches all its containing files
+   - glob pattern matching all the files restricted to be imported
+   - an array of multiple directory string path
+   - an array of multiple glob patterns
+ - `except` may be defined for a zone, allowing exception paths that would otherwise violate the related `from`. Note that it does not alter the behaviour of `target` in any way.
+   - in case `from` contains only glob patterns, `except` must be an array of glob patterns as well
+   - in case `from` contains only directory path, `except` is relative to `from` and cannot backtrack to a parent directory
+ - `message` - will be displayed in case of the rule violation.
 
 ### Examples
 
 Given the following folder structure:
 
-```
+```pt
 my-project
 ├── client
 │   └── foo.js
@@ -58,7 +59,7 @@ import baz from '../client/baz';
 
 Given the following folder structure:
 
-```
+```pt
 my-project
 ├── client
 │   └── foo.js
@@ -74,7 +75,7 @@ and the current file being linted is `my-project/server/one/a.js`.
 
 and the current configuration is set to:
 
-```
+```json
 { "zones": [ {
     "target": "./tests/files/restricted-paths/server/one",
     "from": "./tests/files/restricted-paths/server",
@@ -99,7 +100,7 @@ import b from './b'
 
 Given the following folder structure:
 
-```
+```pt
 my-project
 ├── client
     └── foo.js
@@ -111,7 +112,7 @@ my-project
 
 and the current configuration is set to:
 
-```
+```json
 { "zones": [ {
     "target": "./tests/files/restricted-paths/client/!(sub-module)/**/*",
     "from": "./tests/files/restricted-paths/client/sub-module/**/*",
@@ -134,7 +135,7 @@ import b from './baz'
 
 Given the following folder structure:
 
-```
+```pt
 my-project
 └── one
    └── a.js
@@ -149,7 +150,7 @@ my-project
 
 and the current configuration is set to:
 
-```
+```json
 {
   "zones": [
     {
@@ -195,4 +196,3 @@ import a from '../one/a'
 ```js
 import a from './a'
 ```
-

node_modules/eslint-plugin-import/docs/rules/no-unassigned-import.md

@@ -3,12 +3,13 @@
 <!-- end auto-generated rule header -->
 
 With both CommonJS' `require` and the ES6 modules' `import` syntax, it is possible to import a module but not to use its result. This can be done explicitly by not assigning the module to as variable. Doing so can mean either of the following things:
-- The module is imported but not used
-- The module has side-effects (like [`should`](https://www.npmjs.com/package/should)). Having side-effects, makes it hard to know whether the module is actually used or can be removed. It can also make it harder to test or mock parts of your application.
+
+ - The module is imported but not used
+ - The module has side-effects (like [`should`](https://www.npmjs.com/package/should)). Having side-effects, makes it hard to know whether the module is actually used or can be removed. It can also make it harder to test or mock parts of your application.
 
 This rule aims to remove modules with side-effects by reporting when a module is imported but not assigned.
 
-### Options
+## Options
 
 This rule supports the following option:
 
@@ -16,7 +17,6 @@ This rule supports the following option:
 
 Note that the globs start from the where the linter is executed (usually project root), but not from each file that includes the source. Learn more in both the pass and fail examples below.
 
-
 ## Fail
 
 ```js
@@ -28,7 +28,6 @@ import '../styles/app.css'
 // {"allow": ["styles/*.css"]}
 ```
 
-
 ## Pass
 
 ```js

node_modules/eslint-plugin-import/docs/rules/no-unresolved.md

@@ -50,6 +50,7 @@ const { default: x } = require('./foo') // ignored
 ```
 
 Both may be provided, too:
+
 ```js
 /*eslint import/no-unresolved: [2, { commonjs: true, amd: true }]*/
 const { default: x } = require('./foo') // reported if './foo' is not found
@@ -84,7 +85,6 @@ const { default: x } = require('./foo') // reported if './foo' is actually './Fo
 
 The `caseSensitive` option does not detect case for the current working directory. The `caseSensitiveStrict` option allows checking `cwd` in resolved path. By default, the option is disabled.
 
-
 ```js
 /*eslint import/no-unresolved: [2, { caseSensitiveStrict: true }]*/
 
@@ -102,9 +102,9 @@ If you're using a module bundler other than Node or Webpack, you may end up with
 
 ## Further Reading
 
-- [Resolver plugins](../../README.md#resolvers)
-- [Node resolver](https://npmjs.com/package/eslint-import-resolver-node) (default)
-- [Webpack resolver](https://npmjs.com/package/eslint-import-resolver-webpack)
-- [`import/ignore`] global setting
+ - [Resolver plugins](../../README.md#resolvers)
+ - [Node resolver](https://npmjs.com/package/eslint-import-resolver-node) (default)
+ - [Webpack resolver](https://npmjs.com/package/eslint-import-resolver-webpack)
+ - [`import/ignore`] global setting
 
 [`import/ignore`]: ../../README.md#importignore

node_modules/eslint-plugin-import/docs/rules/no-unused-modules.md

@@ -3,19 +3,20 @@
 <!-- end auto-generated rule header -->
 
 Reports:
-  - modules without any exports
-  - individual exports not being statically `import`ed or `require`ed from other modules in the same project
-  - dynamic imports are supported if argument is a literal string
 
+ - modules without any exports
+ - individual exports not being statically `import`ed or `require`ed from other modules in the same project
+ - dynamic imports are supported if argument is a literal string
 
 ## Rule Details
 
 ### Usage
 
-In order for this plugin to work, at least one of the options `missingExports` or `unusedExports` must be enabled (see "Options" section below). In the future, these options will be enabled by default (see https://github.com/import-js/eslint-plugin-import/issues/1324)
+In order for this plugin to work, at least one of the options `missingExports` or `unusedExports` must be enabled (see "Options" section below). In the future, these options will be enabled by default (see <https://github.com/import-js/eslint-plugin-import/issues/1324>)
 
 Example:
-```
+
+```json
 "rules: {
   ...otherRules,
   "import/no-unused-modules": [1, {"unusedExports": true}]
@@ -26,14 +27,15 @@ Example:
 
 This rule takes the following option:
 
-- **`missingExports`**: if `true`, files without any exports are reported (defaults to `false`)
-- **`unusedExports`**: if `true`, exports without any static usage within other modules are reported (defaults to `false`)
-- `src`: an array with files/paths to be analyzed. It only applies to unused exports. Defaults to `process.cwd()`, if not provided
-- `ignoreExports`: an array with files/paths for which unused exports will not be reported (e.g module entry points in a published package)
-
+ - **`missingExports`**: if `true`, files without any exports are reported (defaults to `false`)
+ - **`unusedExports`**: if `true`, exports without any static usage within other modules are reported (defaults to `false`)
+ - `src`: an array with files/paths to be analyzed. It only applies to unused exports. Defaults to `process.cwd()`, if not provided
+ - `ignoreExports`: an array with files/paths for which unused exports will not be reported (e.g module entry points in a published package)
 
 ### Example for missing exports
+
 #### The following will be reported
+
 ```js
 const class MyClass { /*...*/ }
 
@@ -45,18 +47,23 @@ function makeClass() { return new MyClass(...arguments) }
 ```js
 export default function () { /*...*/ }
 ```
+
 ```js
 export const foo = function () { /*...*/ }
 ```
+
 ```js
 export { foo, bar }
 ```
+
 ```js
 export { foo as bar }
 ```
 
 ### Example for unused exports
+
 given file-f:
+
 ```js
 import { e } from 'file-a'
 import { f } from 'file-b'
@@ -65,24 +72,32 @@ export { default, i0 } from 'file-d' // both will be reported
 
 export const j = 99 // will be reported
 ```
+
 and file-d:
+
 ```js
 export const i0 = 9 // will not be reported
 export const i1 = 9 // will be reported
 export default () => {} // will not be reported
 ```
+
 and file-c:
+
 ```js
 export const h = 8 // will not be reported
 export default () => {} // will be reported, as export * only considers named exports and ignores default exports
 ```
+
 and file-b:
+
 ```js
 import two, { b, c, doAnything } from 'file-a'
 
 export const f = 6 // will not be reported
 ```
+
 and file-a:
+
 ```js
 const b = 2
 const c = 3
@@ -102,6 +117,7 @@ export default 5 // will not be reported
 ```
 
 #### Important Note
+
 Exports from files listed as a main file (`main`, `browser`, or `bin` fields in `package.json`) will be ignored by default. This only applies if the `package.json` is not set to `private: true`
 
 ## When not to use

node_modules/eslint-plugin-import/docs/rules/no-useless-path-segments.md

@@ -10,7 +10,7 @@ Use this rule to prevent unnecessary path segments in import and require stateme
 
 Given the following folder structure:
 
-```
+```pt
 my-project
 ├── app.js
 ├── footer.js
@@ -62,6 +62,7 @@ import fs from "fs";
 ### noUselessIndex
 
 If you want to detect unnecessary `/index` or `/index.js` (depending on the specified file extensions, see below) imports in your paths, you can enable the option `noUselessIndex`. By default it is set to `false`:
+
 ```js
 "import/no-useless-path-segments": ["error", {
   noUselessIndex: true,

node_modules/eslint-plugin-import/docs/rules/no-webpack-loader-syntax.md

@@ -5,6 +5,7 @@
 Forbid Webpack loader syntax in imports.
 
 [Webpack](https://webpack.js.org) allows specifying the [loaders](https://webpack.js.org/concepts/loaders/) to use in the import source string using a special syntax like this:
+
 ```js
 var moduleWithOneLoader = require("my-loader!./my-awesome-module");
 ```

node_modules/eslint-plugin-import/docs/rules/order.md

@@ -5,7 +5,6 @@
 <!-- end auto-generated rule header -->
 
 Enforce a convention in the order of `require()` / `import` statements.
-+(fixable) The `--fix` option on the [command line] automatically fixes problems reported by this rule.
 
 With the [`groups`](#groups-array) option set to `["builtin", "external", "internal", "parent", "sibling", "index", "object", "type"]` the order is as shown in the following example:
 
@@ -37,7 +36,6 @@ Unassigned imports are ignored, as the order they are imported in may be importa
 
 Statements using the ES6 `import` syntax must appear before any `require()` statements.
 
-
 ## Fail
 
 ```ts
@@ -55,7 +53,6 @@ var path = require('path');
 import foo from './foo'; // `import` statements must be before `require` statement
 ```
 
-
 ## Pass
 
 ```ts
@@ -84,11 +81,12 @@ var path = require('path');
 
 This rule supports the following options:
 
-### `groups: [array]`:
+### `groups: [array]`
 
 How groups are defined, and the order to respect. `groups` must be an array of `string` or [`string`]. The only allowed `string`s are:
 `"builtin"`, `"external"`, `"internal"`, `"unknown"`, `"parent"`, `"sibling"`, `"index"`, `"object"`, `"type"`.
 The enforced order is the same as the order of each element in a group. Omitted types are implicitly grouped together as the last element. Example:
+
 ```ts
 [
   'builtin', // Built-in types are first
@@ -98,6 +96,7 @@ The enforced order is the same as the order of each element in a group. Omitted
   // Then the rest: internal and external type
 ]
 ```
+
 The default value is `["builtin", "external", "parent", "sibling", "index"]`.
 
 You can set the options like this:
@@ -120,7 +119,7 @@ You can set the options like this:
 ]
 ```
 
-### `pathGroups: [array of objects]`:
+### `pathGroups: [array of objects]`
 
 To be able to group by paths mostly needed with aliases pathGroups can be defined.
 
@@ -146,7 +145,7 @@ Properties of the objects
 }
 ```
 
-### `distinctGroup: [boolean]`:
+### `distinctGroup: [boolean]`
 
 This changes how `pathGroups[].position` affects grouping. The property is most useful when `newlines-between` is set to `always` and at least 1 `pathGroups` entry has a `position` property set.
 
@@ -155,6 +154,7 @@ By default, in the context of a particular `pathGroup` entry, when setting `posi
 Note that currently, `distinctGroup` defaults to `true`. However, in a later update, the default will change to `false`
 
 Example:
+
 ```json
 {
   "import/order": ["error", {
@@ -171,12 +171,13 @@ Example:
 }
 ```
 
-### `pathGroupsExcludedImportTypes: [array]`:
+### `pathGroupsExcludedImportTypes: [array]`
 
 This defines import types that are not handled by configured pathGroups.
 This is mostly needed when you want to handle path groups that look like external imports.
 
 Example:
+
 ```json
 {
   "import/order": ["error", {
@@ -195,6 +196,7 @@ Example:
 You can also use `patterns`(e.g., `react`, `react-router-dom`, etc).
 
 Example:
+
 ```json
 {
   "import/order": [
@@ -212,16 +214,17 @@ Example:
   ]
 }
 ```
+
 The default value is `["builtin", "external", "object"]`.
 
-### `newlines-between: [ignore|always|always-and-inside-groups|never]`:
+### `newlines-between: [ignore|always|always-and-inside-groups|never]`
 
 Enforces or forbids new lines between import groups:
 
-- If set to `ignore`, no errors related to new lines between import groups will be reported.
-- If set to `always`, at least one new line between each group will be enforced, and new lines inside a group will be forbidden. To prevent multiple lines between imports, core `no-multiple-empty-lines` rule can be used.
-- If set to `always-and-inside-groups`, it will act like `always` except newlines are allowed inside import groups.
-- If set to `never`, no new lines are allowed in the entire import section.
+ - If set to `ignore`, no errors related to new lines between import groups will be reported.
+ - If set to `always`, at least one new line between each group will be enforced, and new lines inside a group will be forbidden. To prevent multiple lines between imports, core `no-multiple-empty-lines` rule can be used.
+ - If set to `always-and-inside-groups`, it will act like `always` except newlines are allowed inside import groups.
+ - If set to `never`, no new lines are allowed in the entire import section.
 
 The default value is `"ignore"`.
 
@@ -285,15 +288,16 @@ import index from './';
 import sibling from './foo';
 ```
 
-### `alphabetize: {order: asc|desc|ignore, orderImportKind: asc|desc|ignore, caseInsensitive: true|false}`:
+### `alphabetize: {order: asc|desc|ignore, orderImportKind: asc|desc|ignore, caseInsensitive: true|false}`
 
 Sort the order within each group in alphabetical manner based on **import path**:
 
-- `order`: use `asc` to sort in ascending order, and `desc` to sort in descending order (default: `ignore`).
-- `orderImportKind`: use `asc` to sort in ascending order various import kinds, e.g. imports prefixed with `type` or `typeof`, with same import path. Use `desc` to sort in descending order (default: `ignore`).
-- `caseInsensitive`: use `true` to ignore case, and `false` to consider case (default: `false`).
+ - `order`: use `asc` to sort in ascending order, and `desc` to sort in descending order (default: `ignore`).
+ - `orderImportKind`: use `asc` to sort in ascending order various import kinds, e.g. imports prefixed with `type` or `typeof`, with same import path. Use `desc` to sort in descending order (default: `ignore`).
+ - `caseInsensitive`: use `true` to ignore case, and `false` to consider case (default: `false`).
 
 Example setting:
+
 ```ts
 alphabetize: {
   order: 'asc', /* sort in ascending order. Options: ['ignore', 'asc', 'desc'] */
@@ -323,9 +327,9 @@ import React, { PureComponent } from 'react';
 import { compose, apply } from 'xcompose';
 ```
 
-### `warnOnUnassignedImports: true|false`:
+### `warnOnUnassignedImports: true|false`
 
-* default: `false`
+ - default: `false`
 
 Warns when unassigned imports are out of order.  These warning will not be fixed
 with `--fix` because unassigned imports are used for side-effects and changing the
@@ -352,9 +356,9 @@ import './styles.css';
 
 ## Related
 
-- [`import/external-module-folders`] setting
+ - [`import/external-module-folders`] setting
 
-- [`import/internal-regex`] setting
+ - [`import/internal-regex`] setting
 
 [`import/external-module-folders`]: ../../README.md#importexternal-module-folders
 

node_modules/eslint-plugin-import/docs/rules/prefer-default-export.md

@@ -6,12 +6,12 @@ In exporting files, this rule checks if there is default export or not.
 
 ## Rule Details
 
-##### rule schema:
+### rule schema
 
 ```javascript
 "import/prefer-default-export": [
     ( "off" | "warn" | "error" ),
-	{ "target": "single" | "any" } // default is "single"
+    { "target": "single" | "any" } // default is "single"
 ]
 ```
 
@@ -109,7 +109,6 @@ How to setup config file for this rule:
 }
 ```
 
-
 The following patterns are *not* considered warnings:
 
 ```javascript

node_modules/eslint-plugin-import/docs/rules/unambiguous.md

@@ -32,6 +32,7 @@ export {} // simple way to mark side-effects-only file as 'module' without any i
 ```
 
 ...whereas the following file would be reported:
+
 ```js
 (function x() { return 42 })()
 ```
@@ -48,9 +49,9 @@ a `module`.
 
 ## Further Reading
 
-- [Unambiguous JavaScript Grammar]
-- [`parserOptions.sourceType`]
-- [node-eps#13](https://github.com/nodejs/node-eps/issues/13)
+ - [Unambiguous JavaScript Grammar]
+ - [`parserOptions.sourceType`]
+ - [node-eps#13](https://github.com/nodejs/node-eps/issues/13)
 
 [`parserOptions.sourceType`]: https://eslint.org/docs/user-guide/configuring#specifying-parser-options
 [Unambiguous JavaScript Grammar]: https://github.com/nodejs/node-eps/blob/HEAD/002-es-modules.md#32-determining-if-source-is-an-es-module

node_modules/eslint-plugin-import/memo-parser/README.md

@@ -1,13 +1,11 @@
 # eslint-plugin-import/memo-parser
 
-
-## NOTE!
+## NOTE
 
 This used to improve performance, but as of ESLint 5 and v2 of this plugin, it seems to just consume a bunch of memory and slightly increase lint times.
 
 **Not recommended for use at this time!**
 
-
 This parser is just a memoizing wrapper around some actual parser.
 
 To configure, just add your _actual_ parser to the `parserOptions`, like so:

node_modules/eslint-plugin-import/package.json

@@ -1,6 +1,6 @@
 {
   "name": "eslint-plugin-import",
-  "version": "2.28.0",
+  "version": "2.28.1",
   "description": "Import with sanity.",
   "engines": {
     "node": ">=4"
@@ -24,7 +24,7 @@
     "copy-metafiles": "node --require babel-register ./scripts/copyMetafiles",
     "watch": "npm run tests-only -- -- --watch",
     "pretest": "linklocal",
-    "posttest": "eslint . && npm run update:eslint-docs -- --check",
+    "posttest": "eslint . && npm run update:eslint-docs -- --check && markdownlint \"**/*.md\"",
     "mocha": "cross-env BABEL_ENV=test nyc mocha",
     "tests-only": "npm run mocha tests/src",
     "test": "npm run tests-only",
@@ -85,8 +85,10 @@
     "fs-copy-file-sync": "^1.1.1",
     "glob": "^7.2.3",
     "in-publish": "^2.0.1",
+    "jackspeak": "=2.1.1",
     "linklocal": "^2.8.2",
     "lodash.isarray": "^4.0.0",
+    "markdownlint-cli": "^0.35.0",
     "mocha": "^3.5.3",
     "npm-which": "^3.0.1",
     "nyc": "^11.9.0",
@@ -110,13 +112,12 @@
     "eslint-import-resolver-node": "^0.3.7",
     "eslint-module-utils": "^2.8.0",
     "has": "^1.0.3",
-    "is-core-module": "^2.12.1",
+    "is-core-module": "^2.13.0",
     "is-glob": "^4.0.3",
     "minimatch": "^3.1.2",
     "object.fromentries": "^2.0.6",
     "object.groupby": "^1.0.0",
     "object.values": "^1.1.6",
-    "resolve": "^1.22.3",
     "semver": "^6.3.1",
     "tsconfig-paths": "^3.14.2"
   }