[Docs] make eslint rule names consistent

Author: ljharb

docs/rules/default.md

@@ -1,4 +1,4 @@
-# default
+# import/default
 
 If a default import is requested, this rule will report if there is no default
 export in the imported module.

docs/rules/export.md

@@ -1,4 +1,4 @@
-# export
+# import/export
 
 Reports funny business with exports, like repeated exports of names or defaults.
 

docs/rules/exports-last.md

@@ -1,4 +1,4 @@
-# exports-last
+# import/exports-last
 
 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.
 

docs/rules/extensions.md

@@ -1,4 +1,4 @@
-# extensions - Ensure consistent use of file extension within the import path
+# import/extensions - Ensure consistent use of file extension within the import path
 
 Some file resolve algorithms allow you to omit the file extension within the import source path. For example the `node` resolver can resolve `./foo/bar` to the absolute path `/User/someone/foo/bar.js` because the `.js` extension is resolved automatically by default. Depending on the resolver you can configure more extensions to get resolved automatically.
 

docs/rules/first.md

@@ -1,4 +1,4 @@
-# first
+# import/first
 
 This rule reports any imports that come after non-import
 statements.

docs/rules/group-exports.md

@@ -1,4 +1,4 @@
-# group-exports
+# import/group-exports
 
 Reports when named exports are not grouped together in a single `export` declaration or when multiple assignments to CommonJS `module.exports` or `exports` object are present in a single file.
 

docs/rules/max-dependencies.md

@@ -1,4 +1,4 @@
-# max-dependencies
+# import/max-dependencies
 
 Forbid modules to have too many dependencies (`import` or `require` statements).
 

docs/rules/named.md

@@ -1,4 +1,4 @@
-# named
+# import/named
 
 Verifies that all named imports are part of the set of named exports in the referenced module.
 

docs/rules/namespace.md

@@ -1,4 +1,4 @@
-# namespace
+# import/namespace
 
 Enforces names exist at the time they are dereferenced, when imported as a full namespace (i.e. `import * as foo from './foo'; foo.bar();` will report if `bar` is not exported by `./foo`.).
 

docs/rules/newline-after-import.md

@@ -1,4 +1,4 @@
-# newline-after-import
+# import/newline-after-import
 
 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.

docs/rules/no-absolute-path.md

@@ -1,4 +1,4 @@
-# Forbid import of modules using absolute paths
+# import/no-absolute-path: Forbid import of modules using absolute paths
 
 Node.js allows the import of modules using an absolute path such as `/home/xyz/file.js`. That is a bad practice as it ties the code using it to your computer, and therefore makes it unusable in packages distributed on `npm` for instance.
 

docs/rules/no-amd.md

@@ -1,4 +1,4 @@
-# no-amd
+# import/no-amd
 
 Reports `require([array], ...)` and `define([array], ...)` function calls at the
 module scope. Will not report if !=2 arguments, or first argument is not a literal array.

docs/rules/no-anonymous-default-export.md

@@ -1,4 +1,4 @@
-# no-anonymous-default-export
+# import/no-anonymous-default-export
 
 Reports if a module's default export is unnamed. This includes several types of unnamed data types; literals, object expressions, arrays, anonymous functions, arrow functions, and anonymous class declarations.
 

docs/rules/no-commonjs.md

@@ -1,4 +1,4 @@
-# no-commonjs
+# import/no-commonjs
 
 Reports `require([string])` function calls. Will not report if >1 argument,
 or single argument is not a literal string.

docs/rules/no-deprecated.md

@@ -1,4 +1,4 @@
-# no-deprecated
+# import/no-deprecated
 
 **Stage: 0**
 

docs/rules/no-duplicates.md

@@ -1,4 +1,4 @@
-# no-duplicates
+# import/no-duplicates
 
 Reports if a resolved path is imported more than once.
 

docs/rules/no-dynamic-require.md

@@ -1,4 +1,4 @@
-# Forbid `require()` calls with expressions
+# import/no-dynamic-require: Forbid `require()` calls with expressions
 
 The `require` method from CommonJS is used to import modules from different files. Unlike the ES6 `import` syntax, it can be given expressions that will be resolved at runtime. While this is sometimes necessary and useful, in most cases it isn't. Using expressions (for instance, concatenating a path and variable) as the argument makes it harder for tools to do static code analysis, or to find where in the codebase a module is used.
 

docs/rules/no-extraneous-dependencies.md

@@ -1,4 +1,4 @@
-# Forbid the use of extraneous packages
+# import/no-extraneous-dependencies: Forbid the use of extraneous packages
 
 Forbid the import of external modules that are not declared in the `package.json`'s `dependencies`, `devDependencies`, `optionalDependencies` or `peerDependencies`.
 The closest parent `package.json` will be used. If no `package.json` is found, the rule will not lint anything. This behaviour can be changed with the rule option `packageDir`.

docs/rules/no-internal-modules.md

@@ -1,4 +1,4 @@
-# no-internal-modules
+# import/no-internal-modules
 
 Use this rule to prevent importing the submodules of other modules.
 

docs/rules/no-mutable-exports.md

@@ -1,4 +1,4 @@
-# no-mutable-exports
+# import/no-mutable-exports
 
 Forbids the use of mutable exports with `var` or `let`.
 

docs/rules/no-named-as-default-member.md

@@ -1,4 +1,4 @@
-# no-named-as-default-member
+# import/no-named-as-default-member
 
 Reports use of an exported name as a property on the default export.
 

docs/rules/no-named-as-default.md

@@ -1,4 +1,4 @@
-# no-named-as-default
+# import/no-named-as-default
 
 Reports use of an exported name as the locally imported name of a default export.
 

docs/rules/no-named-default.md

@@ -1,4 +1,4 @@
-# no-named-default
+# import/no-named-default
 
 Reports use of a default export as a locally named import.
 

docs/rules/no-namespace.md

@@ -1,4 +1,4 @@
-# no-namespace
+# import/no-namespace
 
 Reports if namespace import is used.
 

docs/rules/no-nodejs-modules.md

@@ -1,4 +1,4 @@
-# No Node.js builtin modules
+# import/no-nodejs-modules: No Node.js builtin modules
 
 Forbid the use of Node.js builtin modules. Can be useful for client-side web projects that do not have access to those modules.
 

docs/rules/no-restricted-paths.md

@@ -1,4 +1,4 @@
-# no-restricted-paths - Restrict which files can be imported in a given folder
+# import/no-restricted-paths: Restrict which files can be imported in a given folder
 
 Some projects contain files which are not always meant to be executed in the same environment.
 For example consider a web application that contains specific code for the server and some specific code for the browser/client. In this case you don’t want to import server-only files in your client code.

docs/rules/no-unassigned-import.md

@@ -1,4 +1,4 @@
-# Forbid unassigned imports
+# import/no-unassigned-import: Forbid unassigned imports
 
 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

docs/rules/no-unresolved.md

@@ -1,4 +1,4 @@
-# no-unresolved
+# import/no-unresolved
 
 Ensures an imported module can be resolved to a module on the local filesystem,
 as defined by standard Node `require.resolve` behavior.

docs/rules/no-webpack-loader-syntax.md

@@ -1,4 +1,4 @@
-# no-webpack-loader-syntax
+# import/no-webpack-loader-syntax
 
 Forbid Webpack loader syntax in imports.
 

docs/rules/order.md

@@ -1,4 +1,4 @@
-# Enforce a convention in module import order
+# import/order: Enforce a convention in module import order
 
 Enforce a convention in the order of `require()` / `import` statements. The order is as shown in the following example:
 

docs/rules/unambiguous.md

@@ -1,4 +1,4 @@
-# unambiguous
+# import/unambiguous
 
 Warn if a `module` could be mistakenly parsed as a `script` by a consumer leveraging
 [Unambiguous JavaScript Grammar] to determine correct parsing goal.