immosquare-cleaner 0.1.34 → 0.1.35

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

@@ -1,125 +0,0 @@
-# import/no-unused-modules
-
-<!-- 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
-
-## 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>)
-
-Example:
-
-```json
-"rules: {
-  ...otherRules,
-  "import/no-unused-modules": [1, {"unusedExports": true}]
-}
-```
-
-### Options
-
-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)
-
-### Example for missing exports
-
-#### The following will be reported
-
-```js
-const class MyClass { /*...*/ }
-
-function makeClass() { return new MyClass(...arguments) }
-```
-
-#### The following will not be reported
-
-```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'
-import * as fileC from  'file-c'
-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
-const d = 4
-
-export const a = 1 // will be reported
-
-export { b, c } // will not be reported
-
-export { d as e } // will not be reported
-
-export function doAnything() {
-  // some code
-}  // will not be reported
-
-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
-
-If you don't mind having unused files or dead code within your codebase, you can disable this rule

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

@@ -1,85 +0,0 @@
-# import/no-useless-path-segments
-
-🔧 This rule is automatically fixable by the [`--fix` CLI option](https://eslint.org/docs/latest/user-guide/command-line-interface#--fix).
-
-<!-- end auto-generated rule header -->
-
-Use this rule to prevent unnecessary path segments in import and require statements.
-
-## Rule Details
-
-Given the following folder structure:
-
-```pt
-my-project
-├── app.js
-├── footer.js
-├── header.js
-└── helpers.js
-└── helpers
-    └── index.js
-├── index.js
-└── pages
-    ├── about.js
-    ├── contact.js
-    └── index.js
-```
-
-The following patterns are considered problems:
-
-```js
-/**
- *  in my-project/app.js
- */
-
-import "./../my-project/pages/about.js"; // should be "./pages/about.js"
-import "./../my-project/pages/about"; // should be "./pages/about"
-import "../my-project/pages/about.js"; // should be "./pages/about.js"
-import "../my-project/pages/about"; // should be "./pages/about"
-import "./pages//about"; // should be "./pages/about"
-import "./pages/"; // should be "./pages"
-import "./pages/index"; // should be "./pages" (except if there is a ./pages.js file)
-import "./pages/index.js"; // should be "./pages" (except if there is a ./pages.js file)
-```
-
-The following patterns are NOT considered problems:
-
-```js
-/**
- *  in my-project/app.js
- */
-
-import "./header.js";
-import "./pages";
-import "./pages/about";
-import ".";
-import "..";
-import fs from "fs";
-```
-
-## Options
-
-### 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,
-}]
-```
-
-Additionally to the patterns described above, the following imports are considered problems if `noUselessIndex` is enabled:
-
-```js
-// in my-project/app.js
-import "./helpers/index"; // should be "./helpers/" (not auto-fixable to `./helpers` because this would lead to an ambiguous import of `./helpers.js` and `./helpers/index.js`)
-import "./pages/index"; // should be "./pages" (auto-fixable)
-import "./pages/index.js"; // should be "./pages" (auto-fixable)
-```
-
-Note: `noUselessIndex` only avoids ambiguous imports for `.js` files if you haven't specified other resolved file extensions. See [Settings: import/extensions](https://github.com/import-js/eslint-plugin-import#importextensions) for details.
-
-### commonjs
-
-When set to `true`, this rule checks CommonJS imports. Default to `false`.

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

@@ -1,39 +0,0 @@
-# import/no-webpack-loader-syntax
-
-<!-- end auto-generated rule header -->
-
-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");
-```
-
-This syntax is non-standard, so it couples the code to Webpack. The recommended way to specify Webpack loader configuration is in a [Webpack configuration file](https://webpack.js.org/concepts/loaders/#configuration).
-
-## Rule Details
-
-### Fail
-
-```js
-import myModule from 'my-loader!my-module';
-import theme from 'style!css!./theme.css';
-
-var myModule = require('my-loader!./my-module');
-var theme = require('style!css!./theme.css');
-```
-
-### Pass
-
-```js
-import myModule from 'my-module';
-import theme from './theme.css';
-
-var myModule = require('my-module');
-var theme = require('./theme.css');
-```
-
-## When Not To Use It
-
-If you have a project that doesn't use Webpack you can safely disable this rule.

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

@@ -1,365 +0,0 @@
-# import/order
-
-🔧 This rule is automatically fixable by the [`--fix` CLI option](https://eslint.org/docs/latest/user-guide/command-line-interface#--fix).
-
-<!-- end auto-generated rule header -->
-
-Enforce a convention in the order of `require()` / `import` statements.
-
-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:
-
-```ts
-// 1. node "builtin" modules
-import fs from 'fs';
-import path from 'path';
-// 2. "external" modules
-import _ from 'lodash';
-import chalk from 'chalk';
-// 3. "internal" modules
-// (if you have configured your path or webpack to handle your internal paths differently)
-import foo from 'src/foo';
-// 4. modules from a "parent" directory
-import foo from '../foo';
-import qux from '../../foo/qux';
-// 5. "sibling" modules from the same or a sibling's directory
-import bar from './bar';
-import baz from './bar/baz';
-// 6. "index" of the current directory
-import main from './';
-// 7. "object"-imports (only available in TypeScript)
-import log = console.log;
-// 8. "type" imports (only available in Flow and TypeScript)
-import type { Foo } from 'foo';
-```
-
-Unassigned imports are ignored, as the order they are imported in may be important.
-
-Statements using the ES6 `import` syntax must appear before any `require()` statements.
-
-## Fail
-
-```ts
-import _ from 'lodash';
-import path from 'path'; // `path` import should occur before import of `lodash`
-
-// -----
-
-var _ = require('lodash');
-var path = require('path'); // `path` import should occur before import of `lodash`
-
-// -----
-
-var path = require('path');
-import foo from './foo'; // `import` statements must be before `require` statement
-```
-
-## Pass
-
-```ts
-import path from 'path';
-import _ from 'lodash';
-
-// -----
-
-var path = require('path');
-var _ = require('lodash');
-
-// -----
-
-// Allowed as ̀`babel-register` is not assigned.
-require('babel-register');
-var path = require('path');
-
-// -----
-
-// Allowed as `import` must be before `require`
-import foo from './foo';
-var path = require('path');
-```
-
-## Options
-
-This rule supports the following options:
-
-### `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
-  ['sibling', 'parent'], // Then sibling and parent types. They can be mingled together
-  'index', // Then the index file
-  'object',
-  // Then the rest: internal and external type
-]
-```
-
-The default value is `["builtin", "external", "parent", "sibling", "index"]`.
-
-You can set the options like this:
-
-```ts
-"import/order": [
-  "error",
-  {
-    "groups": [
-      "index",
-      "sibling",
-      "parent",
-      "internal",
-      "external",
-      "builtin",
-      "object",
-      "type"
-    ]
-  }
-]
-```
-
-### `pathGroups: [array of objects]`
-
-To be able to group by paths mostly needed with aliases pathGroups can be defined.
-
-Properties of the objects
-
-| property       | required | type   | description   |
-|----------------|:--------:|--------|---------------|
-| pattern        |     x    | string | minimatch pattern for the paths to be in this group (will not be used for builtins or externals) |
-| patternOptions |          | object | options for minimatch, default: { nocomment: true } |
-| group          |     x    | string | one of the allowed groups, the pathGroup will be positioned relative to this group |
-| position       |          | string | defines where around the group the pathGroup will be positioned, can be 'after' or 'before', if not provided pathGroup will be positioned like the group |
-
-```json
-{
-  "import/order": ["error", {
-    "pathGroups": [
-      {
-        "pattern": "~/**",
-        "group": "external"
-      }
-    ]
-  }]
-}
-```
-
-### `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.
-
-By default, in the context of a particular `pathGroup` entry, when setting `position`, a new "group" will silently be created. That is, even if the `group` is specified, a newline will still separate imports that match that `pattern` with the rest of the group (assuming `newlines-between` is `always`). This is undesirable if your intentions are to use `position` to position _within_ the group (and not create a new one). Override this behavior by setting `distinctGroup` to `false`; this will keep imports within the same group as intended.
-
-Note that currently, `distinctGroup` defaults to `true`. However, in a later update, the default will change to `false`
-
-Example:
-
-```json
-{
-  "import/order": ["error", {
-    "newlines-between": "always",
-    "pathGroups": [
-      {
-        "pattern": "@app/**",
-        "group": "external",
-        "position": "after"
-      }
-    ],
-    "distinctGroup": false
-  }]
-}
-```
-
-### `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", {
-    "pathGroups": [
-      {
-        "pattern": "@app/**",
-        "group": "external",
-        "position": "after"
-      }
-    ],
-    "pathGroupsExcludedImportTypes": ["builtin"]
-  }]
-}
-```
-
-You can also use `patterns`(e.g., `react`, `react-router-dom`, etc).
-
-Example:
-
-```json
-{
-  "import/order": [
-    "error",
-    {
-      "pathGroups": [
-        {
-          "pattern": "react",
-          "group": "builtin",
-          "position": "before"
-        }
-      ],
-      "pathGroupsExcludedImportTypes": ["react"]
-    }
-  ]
-}
-```
-
-The default value is `["builtin", "external", "object"]`.
-
-### `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.
-
-The default value is `"ignore"`.
-
-With the default group setting, the following will be invalid:
-
-```ts
-/* eslint import/order: ["error", {"newlines-between": "always"}] */
-import fs from 'fs';
-import path from 'path';
-import index from './';
-import sibling from './foo';
-```
-
-```ts
-/* eslint import/order: ["error", {"newlines-between": "always-and-inside-groups"}] */
-import fs from 'fs';
-
-import path from 'path';
-import index from './';
-import sibling from './foo';
-```
-
-```ts
-/* eslint import/order: ["error", {"newlines-between": "never"}] */
-import fs from 'fs';
-import path from 'path';
-
-import index from './';
-
-import sibling from './foo';
-```
-
-while those will be valid:
-
-```ts
-/* eslint import/order: ["error", {"newlines-between": "always"}] */
-import fs from 'fs';
-import path from 'path';
-
-import index from './';
-
-import sibling from './foo';
-```
-
-```ts
-/* eslint import/order: ["error", {"newlines-between": "always-and-inside-groups"}] */
-import fs from 'fs';
-
-import path from 'path';
-
-import index from './';
-
-import sibling from './foo';
-```
-
-```ts
-/* eslint import/order: ["error", {"newlines-between": "never"}] */
-import fs from 'fs';
-import path from 'path';
-import index from './';
-import sibling from './foo';
-```
-
-### `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`).
-
-Example setting:
-
-```ts
-alphabetize: {
-  order: 'asc', /* sort in ascending order. Options: ['ignore', 'asc', 'desc'] */
-  caseInsensitive: true /* ignore case. Options: [true, false] */
-}
-```
-
-This will fail the rule check:
-
-```ts
-/* eslint import/order: ["error", {"alphabetize": {"order": "asc", "caseInsensitive": true}}] */
-import React, { PureComponent } from 'react';
-import aTypes from 'prop-types';
-import { compose, apply } from 'xcompose';
-import * as classnames from 'classnames';
-import blist from 'BList';
-```
-
-While this will pass:
-
-```ts
-/* eslint import/order: ["error", {"alphabetize": {"order": "asc", "caseInsensitive": true}}] */
-import blist from 'BList';
-import * as classnames from 'classnames';
-import aTypes from 'prop-types';
-import React, { PureComponent } from 'react';
-import { compose, apply } from 'xcompose';
-```
-
-### `warnOnUnassignedImports: true|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
-import of order of modules with side effects can not be done automatically in a
-way that is safe.
-
-This will fail the rule check:
-
-```ts
-/* eslint import/order: ["error", {"warnOnUnassignedImports": true}] */
-import fs from 'fs';
-import './styles.css';
-import path from 'path';
-```
-
-While this will pass:
-
-```ts
-/* eslint import/order: ["error", {"warnOnUnassignedImports": true}] */
-import fs from 'fs';
-import path from 'path';
-import './styles.css';
-```
-
-## Related
-
- - [`import/external-module-folders`] setting
-
- - [`import/internal-regex`] setting
-
-[`import/external-module-folders`]: ../../README.md#importexternal-module-folders
-
-[`import/internal-regex`]: ../../README.md#importinternal-regex