immosquare-cleaner 0.1.34 → 0.1.35

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

@@ -1,75 +0,0 @@
-# import/first
-
-🔧 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 -->
-
-This rule reports any imports that come after non-import
-statements.
-
-## Rule Details
-
-```js
-import foo from './foo'
-
-// some module-level initializer
-initWith(foo)
-
-import bar from './bar' // <- reported
-```
-
-Providing `absolute-first` as an option will report any absolute imports (i.e.
-packages) that come after any relative imports:
-
-```js
-import foo from 'foo'
-import bar from './bar'
-
-import * as _ from 'lodash' // <- reported
-```
-
-If you really want import type ordering, check out [`import/order`].
-
-Notably, `import`s are hoisted, which means the imported modules will be evaluated
-before any of the statements interspersed between them. Keeping all `import`s together
-at the top of the file may prevent surprises resulting from this part of the spec.
-
-### On directives
-
-Directives are allowed as long as they occur strictly before any `import` declarations,
-as follows:
-
-```js
-'use super-mega-strict'
-
-import { suchFoo } from 'lame-fake-module-name'  // no report here
-```
-
-A directive in this case is assumed to be a single statement that contains only
-a literal string-valued expression.
-
-`'use strict'` would be a good example, except that [modules are always in strict
-mode](https://262.ecma-international.org/6.0/#sec-strict-mode-code) so it would be surprising to see a `'use strict'` sharing a file with `import`s and
-`export`s.
-
-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.
-
-## When Not To Use It
-
-If you don't mind imports being sprinkled throughout, you may not want to
-enable this rule.
-
-## Further Reading
-
- - [`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

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

@@ -1,118 +0,0 @@
-# import/group-exports
-
-<!-- end auto-generated rule header -->
-
-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.
-
-**Rationale:** An `export` declaration or `module.exports` assignment can appear anywhere in the code. By requiring a single export declaration all your exports will remain at one place, making it easier to see what exports a module provides.
-
-## Rule Details
-
-This rule warns whenever a single file contains multiple named export declarations or multiple assignments to `module.exports` (or `exports`).
-
-### Valid
-
-```js
-// A single named export declaration -> ok
-export const valid = true
-```
-
-```js
-const first = true
-const second = true
-
-// A single named export declaration -> ok
-export {
-  first,
-  second,
-}
-```
-
-```js
-// Aggregating exports -> ok
-export { default as module1 } from 'module-1'
-export { default as module2 } from 'module-2'
-```
-
-```js
-// A single exports assignment -> ok
-module.exports = {
-  first: true,
-  second: true
-}
-```
-
-```js
-const first = true
-const second = true
-
-// A single exports assignment -> ok
-module.exports = {
-  first,
-  second,
-}
-```
-
-```js
-function test() {}
-test.property = true
-test.another = true
-
-// A single exports assignment -> ok
-module.exports = test
-```
-
-```ts
-const first = true;
-type firstType = boolean
-
-// A single named export declaration (type exports handled separately) -> ok
-export {first}
-export type {firstType}
-```
-
-### Invalid
-
-```js
-// Multiple named export statements -> not ok!
-export const first = true
-export const second = true
-```
-
-```js
-// Aggregating exports from the same module -> not ok!
-export { module1 } from 'module-1'
-export { module2 } from 'module-1'
-```
-
-```js
-// Multiple exports assignments -> not ok!
-exports.first = true
-exports.second = true
-```
-
-```js
-// Multiple exports assignments -> not ok!
-module.exports = {}
-module.exports.first = true
-```
-
-```js
-// Multiple exports assignments -> not ok!
-module.exports = () => {}
-module.exports.first = true
-module.exports.second = true
-```
-
-```ts
-type firstType = boolean
-type secondType = any
-
-// Multiple named type export statements -> not ok!
-export type {firstType}
-export type {secondType}
-```
-
-## When Not To Use It
-
-If you do not mind having your exports spread across the file, you can safely turn this rule off.

data/node_modules/eslint-plugin-import/docs/rules/imports-first.md

@@ -1,9 +0,0 @@
-# import/imports-first
-
-❌ This rule is deprecated.
-
-🔧 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 -->
-
-This rule was **deprecated** in eslint-plugin-import v2.0.0. Please use the corresponding rule [`first`](https://github.com/import-js/eslint-plugin-import/blob/HEAD/docs/rules/first.md).

data/node_modules/eslint-plugin-import/docs/rules/max-dependencies.md

@@ -1,70 +0,0 @@
-# import/max-dependencies
-
-<!-- end auto-generated rule header -->
-
-Forbid modules to have too many dependencies (`import` or `require` statements).
-
-This is a useful rule because a module with too many dependencies is a code smell, and usually indicates the module is doing too much and/or should be broken up into smaller modules.
-
-Importing multiple named exports from a single module will only count once (e.g. `import {x, y, z} from './foo'` will only count as a single dependency).
-
-## Options
-
-This rule has the following options, with these defaults:
-
-```js
-"import/max-dependencies": ["error", {
-  "max": 10,
-  "ignoreTypeImports": false,
-}]
-```
-
-### `max`
-
-This option sets the maximum number of dependencies allowed. Anything over will trigger the rule. **Default is 10** if the rule is enabled and no `max` is specified.
-
-Given a max value of `{"max": 2}`:
-
-### Fail
-
-```js
-import a from './a'; // 1
-const b = require('./b'); // 2
-import c from './c'; // 3 - exceeds max!
-```
-
-### Pass
-
-```js
-import a from './a'; // 1
-const anotherA = require('./a'); // still 1
-import {x, y, z} from './foo'; // 2
-```
-
-### `ignoreTypeImports`
-
-Ignores `type` imports. Type imports are a feature released in TypeScript 3.8, you can [read more here](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html#type-only-imports-and-export). Defaults to `false`.
-
-Given `{"max": 2, "ignoreTypeImports": true}`:
-
-<!-- markdownlint-disable-next-line MD024 -- duplicate header -->
-### Fail
-
-```ts
-import a from './a';
-import b from './b';
-import c from './c';
-```
-
-<!-- markdownlint-disable-next-line MD024 -- duplicate header -->
-### Pass
-
-```ts
-import a from './a';
-import b from './b';
-import type c from './c'; // Doesn't count against max
-```
-
-## When Not To Use It
-
-If you don't care how many dependencies a module has.

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

@@ -1,102 +0,0 @@
-# import/named
-
-💼🚫 This rule is enabled in the following configs: ❗ `errors`, ☑️ `recommended`. This rule is _disabled_ in the ⌨️ `typescript` config.
-
-<!-- end auto-generated rule header -->
-
-Verifies that all named imports are part of the set of named exports in the referenced module.
-
-For `export`, verifies that all named exports exist in the referenced module.
-
-Note: for packages, the plugin will find exported names
-from [`jsnext:main`] (deprecated) or `module`, if present in `package.json`.
-Redux's npm module includes this key, and thereby is lintable, for example.
-
-A module path that is [ignored] or not [unambiguously an ES module] will not be reported when imported. Note that type imports and exports, as used by [Flow], are always ignored.
-
-[ignored]: ../../README.md#importignore
-[unambiguously an ES module]: https://github.com/bmeck/UnambiguousJavaScriptGrammar
-[Flow]: https://flow.org/
-
-## Rule Details
-
-Given:
-
-```js
-// ./foo.js
-export const foo = "I'm so foo"
-```
-
-The following is considered valid:
-
-```js
-// ./bar.js
-import { foo } from './foo'
-
-// ES7 proposal
-export { foo as bar } from './foo'
-
-// node_modules without jsnext:main are not analyzed by default
-// (import/ignore setting)
-import { SomeNonsenseThatDoesntExist } from 'react'
-```
-
-...and the following are reported:
-
-```js
-// ./baz.js
-import { notFoo } from './foo'
-
-// ES7 proposal
-export { notFoo as defNotBar } from './foo'
-
-// will follow 'jsnext:main', if available
-import { dontCreateStore } from 'redux'
-```
-
-### Settings
-
-[`import/ignore`] can be provided as a setting to ignore certain modules (node_modules,
-CoffeeScript, CSS if using Webpack, etc.).
-
-Given:
-
-```yaml
-# .eslintrc (YAML)
----
-settings:
-  import/ignore:
-    - node_modules  # included by default, but replaced if explicitly configured
-    - *.coffee$     # can't parse CoffeeScript (unless a custom polyglot parser was configured)
-```
-
-and
-
-```coffeescript
-# ./whatever.coffee
-exports.whatever = (foo) -> console.log foo
-```
-
-then the following is not reported:
-
-```js
-// ./foo.js
-
-// can't be analyzed, and ignored, so not reported
-import { notWhatever } from './whatever'
-```
-
-## When Not To Use It
-
-If you are using CommonJS and/or modifying the exported namespace of any module at
-runtime, you will likely see false positives with this rule.
-
-## Further Reading
-
- - [`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
-[`import/ignore`]: ../../README.md#importignore

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

@@ -1,106 +0,0 @@
-# import/namespace
-
-💼 This rule is enabled in the following configs: ❗ `errors`, ☑️ `recommended`.
-
-<!-- end auto-generated rule header -->
-
-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`.).
-
-Will report at the import declaration if there are _no_ exported names found.
-
-Also, will report for computed references (i.e. `foo["bar"]()`).
-
-Reports on assignment to a member of an imported namespace.
-
-Note: for packages, the plugin will find exported names
-from [`jsnext:main`], if present in `package.json`.
-Redux's npm module includes this key, and thereby is lintable, for example.
-
-A module path that is [ignored] or not [unambiguously an ES module] will not be reported when imported.
-
-[ignored]: ../README.md#importignore
-[unambiguously an ES module]: https://github.com/bmeck/UnambiguousJavaScriptGrammar
-
-## Rule Details
-
-Currently, this rule does not check for possible
-redefinition of the namespace in an intermediate scope. Adherence to the ESLint
-`no-shadow` rule for namespaces will prevent this from being a problem.
-
-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
-const b = 2
-export { b }
-
-const c = 3
-export { c as d }
-
-export class ExportedClass { }
-
-// ES7
-export * as deep from './deep'
-```
-
-and:
-
-```js
-// @module ./deep
-export const e = "MC2"
-```
-
-See what is valid and reported:
-
-```js
-// @module ./foo
-import * as names from './named-exports'
-
-function great() {
-  return names.a + names.b  // so great https://youtu.be/ei7mb8UxEl8
-}
-
-function notGreat() {
-  doSomethingWith(names.c) // Reported: 'c' not found in imported namespace 'names'.
-
-  const { a, b, c } = names // also reported, only for 'c'
-}
-
-// also tunnels through re-exported namespaces!
-function deepTrouble() {
-  doSomethingWith(names.deep.e) // fine
-  doSomethingWith(names.deep.f) // Reported: 'f' not found in deeply imported namespace 'names.deep'.
-}
-
-```
-
-### Options
-
-#### `allowComputed`
-
-Defaults to `false`. When false, will report the following:
-
-```js
-/*eslint import/namespace: [2, { allowComputed: false }]*/
-import * as a from './a'
-
-function f(x) {
-  return a[x] // Unable to validate computed reference to imported namespace 'a'.
-}
-```
-
-When set to `true`, the above computed namespace member reference is allowed, but
-still can't be statically analyzed any further.
-
-## Further Reading
-
- - 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
-[`jsnext:main`]: https://github.com/rollup/rollup/wiki/jsnext:main

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

@@ -1,167 +0,0 @@
-# import/newline-after-import
-
-🔧 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 -->
-
-Enforces having one or more empty lines after the last top-level import statement or require call.
-
-## 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`.
-
- - `exactCount` which enforce the exact numbers of newlines that is mentioned in `count`. This option defaults to `false`.
-
- - `considerComments` which enforces the rule on comments after the last import-statement as well when set to true. This option defaults to `false`.
-
-Valid:
-
-```js
-import defaultExport from './foo';
-
-const FOO = 'BAR';
-```
-
-```js
-import defaultExport from './foo';
-import { bar }  from 'bar-lib';
-
-const FOO = 'BAR';
-```
-
-```js
-const FOO = require('./foo');
-const BAR = require('./bar');
-
-const BAZ = 1;
-```
-
-Invalid:
-
-```js
-import * as foo from 'foo'
-const FOO = 'BAR';
-```
-
-```js
-import * as foo from 'foo';
-const FOO = 'BAR';
-
-import { bar }  from 'bar-lib';
-```
-
-```js
-const FOO = require('./foo');
-const BAZ = 1;
-const BAR = require('./bar');
-```
-
-With `count` set to `2` this will be considered valid:
-
-```js
-import defaultExport from './foo';
-
-
-const FOO = 'BAR';
-```
-
-```js
-import defaultExport from './foo';
-
-
-
-const FOO = 'BAR';
-```
-
-With `count` set to `2` these will be considered invalid:
-
-```js
-import defaultExport from './foo';
-const FOO = 'BAR';
-```
-
-```js
-import defaultExport from './foo';
-
-const FOO = 'BAR';
-```
-
-With `count` set to `2` and `exactCount` set to `true` this will be considered valid:
-
-```js
-import defaultExport from './foo';
-
-
-const FOO = 'BAR';
-```
-
-With `count` set to `2` and `exactCount` set to `true` these will be considered invalid:
-
-```js
-import defaultExport from './foo';
-const FOO = 'BAR';
-```
-
-```js
-import defaultExport from './foo';
-
-const FOO = 'BAR';
-```
-
-```js
-import defaultExport from './foo';
-
-
-
-const FOO = 'BAR';
-```
-
-```js
-import defaultExport from './foo';
-
-
-
-
-const FOO = 'BAR';
-```
-
-With `considerComments` set to `false` this will be considered valid:
-
-```js
-import defaultExport from './foo'
-// some comment here.
-const FOO = 'BAR'
-```
-
-With `considerComments` set to `true` this will be considered valid:
-
-```js
-import defaultExport from './foo'
-
-// some comment here.
-const FOO = 'BAR'
-```
-
-With `considerComments` set to `true` this will be considered invalid:
-
-```js
-import defaultExport from './foo'
-// some comment here.
-const FOO = 'BAR'
-```
-
-## Example options usage
-
-```json
-{
-  "rules": {
-    "import/newline-after-import": ["error", { "count": 2 }]
-  }
-}
-```
-
-## When Not To Use It
-
-If you like to visually group module imports with its usage, you don't want to use this rule.

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

@@ -1,54 +0,0 @@
-# import/no-absolute-path
-
-🔧 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 -->
-
-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.
-
-This rule forbids the import of modules using absolute paths.
-
-## Rule Details
-
-### Fail
-
-```js
-import f from '/foo';
-import f from '/some/path';
-
-var f = require('/foo');
-var f = require('/some/path');
-```
-
-### Pass
-
-```js
-import _ from 'lodash';
-import foo from 'foo';
-import foo from './foo';
-
-var _ = require('lodash');
-var foo = require('foo');
-var foo = require('./foo');
-```
-
-### Options
-
-By default, only ES6 imports and CommonJS `require` calls will have this rule enforced.
-
-You may provide an options object providing true/false for any of
-
- - `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:
-
-```js
-/*eslint import/no-absolute-path: [2, { commonjs: false, amd: true }]*/
-define(['/foo'], function (foo) { /*...*/ }) // reported
-require(['/foo'], function (foo) { /*...*/ }) // reported
-
-const foo = require('/foo') // ignored because of explicit `commonjs: false`
-```