immosquare-cleaner 0.1.34 → 0.1.35

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

@@ -1,37 +0,0 @@
-# import/no-amd
-
-<!-- end auto-generated rule header -->
-
-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.
-
-Intended for temporary use when migrating to pure ES6 modules.
-
-## Rule Details
-
-This will be reported:
-
-```js
-define(["a", "b"], function (a, b) { /* ... */ })
-
-require(["b", "c"], function (b, c) { /* ... */ })
-```
-
-CommonJS `require` is still valid.
-
-## When Not To Use It
-
-If you don't mind mixing module systems (sometimes this is useful), you probably
-don't want this rule.
-
-It is also fairly noisy if you have a larger codebase that is being transitioned
-from AMD to ES6 modules.
-
-## Contributors
-
-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>

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

@@ -1,83 +0,0 @@
-# import/no-anonymous-default-export
-
-<!-- end auto-generated rule header -->
-
-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.
-
-Ensuring that default exports are named helps improve the grepability of the codebase by encouraging the re-use of the same identifier for the module's default export at its declaration site and at its import sites.
-
-## Options
-
-By default, all types of anonymous default exports are forbidden, but any types can be selectively allowed by toggling them on in the options.
-
-The complete default configuration looks like this.
-
-```js
-"import/no-anonymous-default-export": ["error", {
-  "allowArray": false,
-  "allowArrowFunction": false,
-  "allowAnonymousClass": false,
-  "allowAnonymousFunction": false,
-  "allowCallExpression": true, // The true value here is for backward compatibility
-  "allowNew": false,
-  "allowLiteral": false,
-  "allowObject": false
-}]
-```
-
-## Rule Details
-
-### Fail
-
-```js
-export default []
-
-export default () => {}
-
-export default class {}
-
-export default function () {}
-
-/* eslint import/no-anonymous-default-export: [2, {"allowCallExpression": false}] */
-export default foo(bar)
-
-export default 123
-
-export default {}
-
-export default new Foo()
-```
-
-### Pass
-
-```js
-const foo = 123
-export default foo
-
-export default class MyClass() {}
-
-export default function foo() {}
-
-/* eslint import/no-anonymous-default-export: [2, {"allowArray": true}] */
-export default []
-
-/* eslint import/no-anonymous-default-export: [2, {"allowArrowFunction": true}] */
-export default () => {}
-
-/* eslint import/no-anonymous-default-export: [2, {"allowAnonymousClass": true}] */
-export default class {}
-
-/* eslint import/no-anonymous-default-export: [2, {"allowAnonymousFunction": true}] */
-export default function () {}
-
-export default foo(bar)
-
-/* eslint import/no-anonymous-default-export: [2, {"allowLiteral": true}] */
-export default 123
-
-/* eslint import/no-anonymous-default-export: [2, {"allowObject": true}] */
-export default {}
-
-/* eslint import/no-anonymous-default-export: [2, {"allowNew": true}] */
-export default new Foo()
-```

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

@@ -1,96 +0,0 @@
-# import/no-commonjs
-
-<!-- end auto-generated rule header -->
-
-Reports `require([string])` function calls. Will not report if >1 argument,
-or single argument is not a literal string.
-
-Reports `module.exports` or `exports.*`, also.
-
-Intended for temporary use when migrating to pure ES6 modules.
-
-## Rule Details
-
-This will be reported:
-
-```js
-var mod = require('./mod')
-  , common = require('./common')
-  , fs = require('fs')
-  , whateverModule = require('./not-found')
-
-module.exports = { a: "b" }
-exports.c = "d"
-```
-
-### Allow require
-
-If `allowRequire` option is set to `true`, `require` calls are valid:
-
-```js
-/*eslint no-commonjs: [2, { allowRequire: true }]*/
-var mod = require('./mod');
-```
-
-but `module.exports` is reported as usual.
-
-### Allow conditional require
-
-By default, conditional requires are allowed:
-
-```js
-var a = b && require("c")
-
-if (typeof window !== "undefined") {
-  require('that-ugly-thing');
-}
-
-var fs = null;
-try {
-  fs = require("fs")
-} catch (error) {}
-```
-
-If the `allowConditionalRequire` option is set to `false`, they will be reported.
-
-If you don't rely on synchronous module loading, check out [dynamic import](https://github.com/airbnb/babel-plugin-dynamic-import-node).
-
-### Allow primitive modules
-
-If `allowPrimitiveModules` option is set to `true`, the following is valid:
-
-```js
-/*eslint no-commonjs: [2, { allowPrimitiveModules: true }]*/
-
-module.exports = "foo"
-module.exports = function rule(context) { return { /* ... */ } }
-```
-
-but this is still reported:
-
-```js
-/*eslint no-commonjs: [2, { allowPrimitiveModules: true }]*/
-
-module.exports = { x: "y" }
-exports.z = function boop() { /* ... */ }
-```
-
-This is useful for things like ESLint rule modules, which must export a function as
-the module.
-
-## When Not To Use It
-
-If you don't mind mixing module systems (sometimes this is useful), you probably
-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>

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

@@ -1,111 +0,0 @@
-# import/no-cycle
-
-<!-- end auto-generated rule header -->
-
-Ensures that there is no resolvable path back to this module via its dependencies.
-
-This includes cycles of depth 1 (imported module imports me) to `"∞"` (or `Infinity`), if the
-[`maxDepth`](#maxdepth) option is not set.
-
-```js
-// dep-b.js
-import './dep-a.js'
-
-export function b() { /* ... */ }
-```
-
-```js
-// dep-a.js
-import { b } from './dep-b.js' // reported: Dependency cycle detected.
-```
-
-This rule does _not_ detect imports that resolve directly to the linted module;
-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
-
-By default, this rule only detects cycles for ES6 imports, but see the [`no-unresolved` options](./no-unresolved.md#options) as this rule also supports the same `commonjs` and `amd` flags. However, these flags only impact which import types are _linted_; the
-import/export infrastructure only registers `import` statements in dependencies, so
-cycles created by `require` within imported modules may not be detected.
-
-#### `maxDepth`
-
-There is a `maxDepth` option available to prevent full expansion of very deep dependency trees:
-
-```js
-/*eslint import/no-cycle: [2, { maxDepth: 1 }]*/
-
-// dep-c.js
-import './dep-a.js'
-```
-
-```js
-// dep-b.js
-import './dep-c.js'
-
-export function b() { /* ... */ }
-```
-
-```js
-// dep-a.js
-import { b } from './dep-b.js' // not reported as the cycle is at depth 2
-```
-
-This is not necessarily recommended, but available as a cost/benefit tradeoff mechanism
-for reducing total project lint time, if needed.
-
-#### `ignoreExternal`
-
-An `ignoreExternal` option is available to prevent the cycle detection to expand to external modules:
-
-```js
-/*eslint import/no-cycle: [2, { ignoreExternal: true }]*/
-
-// dep-a.js
-import 'module-b/dep-b.js'
-
-export function a() { /* ... */ }
-```
-
-```js
-// node_modules/module-b/dep-b.js
-import { a } from './dep-a.js' // not reported as this module is external
-```
-
-Its value is `false` by default, but can be set to `true` for reducing total project lint time, if needed.
-
-#### `allowUnsafeDynamicCyclicDependency`
-
-This option disable reporting of errors if a cycle is detected with at least one dynamic import.
-
-```js
-// bar.js
-import { foo } from './foo';
-export const bar = foo;
-
-// foo.js
-export const foo = 'Foo';
-export function getBar() { return import('./bar'); }
-```
-
-> Cyclic dependency are **always** a dangerous anti-pattern as discussed extensively in [#2265](https://github.com/import-js/eslint-plugin-import/issues/2265). Please be extra careful about using this option.
-
-## When Not To Use It
-
-This rule is comparatively computationally expensive. If you are pressed for lint
-time, or don't think you have an issue with dependency cycles, you may not want
-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
-
-[`no-self-import`]: ./no-self-import.md
-
-[`import/external-module-folders`]: ../../README.md#importexternal-module-folders

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

@@ -1,65 +0,0 @@
-# import/no-default-export
-
-<!-- end auto-generated rule header -->
-
-Prohibit default exports. Mostly an inverse of [`prefer-default-export`].
-
-[`prefer-default-export`]: ./prefer-default-export.md
-
-## Rule Details
-
-The following patterns are considered warnings:
-
-```javascript
-// bad1.js
-
-// There is a default export.
-export const foo = 'foo';
-const bar = 'bar';
-export default 'bar';
-```
-
-```javascript
-// bad2.js
-
-// There is a default export.
-const foo = 'foo';
-export { foo as default }
-```
-
-The following patterns are not warnings:
-
-```javascript
-// good1.js
-
-// There is only a single module export and it's a named export.
-export const foo = 'foo';
-```
-
-```javascript
-// good2.js
-
-// There is more than one named export in the module.
-export const foo = 'foo';
-export const bar = 'bar';
-```
-
-```javascript
-// good3.js
-
-// There is more than one named export in the module
-const foo = 'foo';
-const bar = 'bar';
-export { foo, bar }
-```
-
-```javascript
-// export-star.js
-
-// Any batch export will disable this rule. The remote module is not inspected.
-export * from './other-module'
-```
-
-## When Not To Use It
-
-If you don't care if default imports are used, or if you prefer default imports over named imports.

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

@@ -1,62 +0,0 @@
-# import/no-deprecated
-
-<!-- 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.
-
-using a JSDoc `@deprecated` tag:
-
-```js
-// @file: ./answer.js
-
-/**
- * this is what you get when you trust a mouse talk show
- * @deprecated need to restart the experiment
- * @returns {Number} nonsense
- */
-export function multiply(six, nine) {
-  return 42
-}
-```
-
-will report as such:
-
-```js
-import { multiply } from './answer' // Deprecated: need to restart the experiment
-
-function whatever(y, z) {
-  return multiply(y, z) // Deprecated: need to restart the experiment
-}
-```
-
-or using the TomDoc equivalent:
-
-```js
-// Deprecated: This is what you get when you trust a mouse talk show, need to
-// restart the experiment.
-//
-// Returns a Number nonsense
-export function multiply(six, nine) {
-  return 42
-}
-```
-
-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
-
- - [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

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

@@ -1,109 +0,0 @@
-# import/no-duplicates
-
-⚠️ This rule _warns_ in the following configs: ☑️ `recommended`, 🚸 `warnings`.
-
-🔧 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 -->
-
-Reports if a resolved path is imported more than once.
-
-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:
-
-1. the paths in the source code don't have to exactly match, they just have to point to the same module on the filesystem. (i.e. `./foo` and `./foo.js`)
-2. this version distinguishes Flow `type` imports from standard imports. ([#334](https://github.com/import-js/eslint-plugin-import/pull/334))
-
-## Rule Details
-
-Valid:
-
-```js
-import SomeDefaultClass, * as names from './mod'
-// Flow `type` import from same module is fine
-import type SomeType from './mod'
-```
-
-...whereas here, both `./mod` imports will be reported:
-
-```js
-import SomeDefaultClass from './mod'
-
-// oops, some other import separated these lines
-import foo from './some-other-mod'
-
-import * as names from './mod'
-
-// will catch this too, assuming it is the same target module
-import { something } from './mod.js'
-```
-
-The motivation is that this is likely a result of two developers importing different
-names from the same module at different times (and potentially largely different
-locations in the file.) This rule brings both (or n-many) to attention.
-
-### Query Strings
-
-By default, this rule ignores query strings (i.e. paths followed by a question mark), and thus imports from `./mod?a` and `./mod?b` will be considered as duplicates. However you can use the option `considerQueryString` to handle them as different (primarily because browsers will resolve those imports differently).
-
-Config:
-
-```json
-"import/no-duplicates": ["error", {"considerQueryString": true}]
-```
-
-And then the following code becomes valid:
-
-```js
-import minifiedMod from './mod?minify'
-import noCommentsMod from './mod?comments=0'
-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'
-
-// This is invalid, assuming `./mod` and `./mod.js` are the same target:
-import * from './mod.js?minify'
-```
-
-### Inline Type imports
-
-TypeScript 4.5 introduced a new [feature](https://devblogs.microsoft.com/typescript/announcing-typescript-4-5/#type-on-import-names) that allows mixing of named value and type imports. In order to support fixing to an inline type import when duplicate imports are detected, `prefer-inline` can be set to true.
-
-Config:
-
-```json
-"import/no-duplicates": ["error", {"prefer-inline": true}]
-```
-
-<!--tabs-->
-
-❌ Invalid `["error", {"prefer-inline": true}]`
-
-```js
-import { AValue, type AType } from './mama-mia'
-import type { BType } from './mama-mia'
-
-import { CValue } from './papa-mia'
-import type { CType } from './papa-mia'
-```
-
-✅ Valid with `["error", {"prefer-inline": true}]`
-
-```js
-import { AValue, type AType, type BType } from './mama-mia'
-
-import { CValue, type CType } from './papa-mia'
-```
-
-<!--tabs-->
-
-## When Not To Use It
-
-If the core ESLint version is good enough (i.e. you're _not_ using Flow and you _are_ using [`import/extensions`](./extensions.md)), keep it and don't use this.
-
-If you like to split up imports across lines or may need to import a default and a namespace,
-you may not want to enable this rule.

data/node_modules/eslint-plugin-import/docs/rules/no-dynamic-require.md

@@ -1,25 +0,0 @@
-# import/no-dynamic-require
-
-<!-- end auto-generated rule header -->
-
-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.
-
-This rule forbids every call to `require()` that uses expressions for the module name argument.
-
-## Rule Details
-
-### Fail
-
-```js
-require(name);
-require('../' + name);
-require(`../${name}`);
-require(name());
-```
-
-### Pass
-
-```js
-require('../name');
-require(`../name`);
-```

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

@@ -1,49 +0,0 @@
-# import/no-empty-named-blocks
-
-🔧💡 This rule is automatically fixable by the [`--fix` CLI option](https://eslint.org/docs/latest/user-guide/command-line-interface#--fix) and manually fixable by [editor suggestions](https://eslint.org/docs/developer-guide/working-with-rules#providing-suggestions).
-
-<!-- end auto-generated rule header -->
-
-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'
-```