immosquare-cleaner 0.1.34 → 0.1.35

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

@@ -1,42 +0,0 @@
-# import/no-nodejs-modules
-
-<!-- end auto-generated rule header -->
-
-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
-
-This rule supports the following options:
-
- - `allow`: Array of names of allowed modules. Defaults to an empty array.
-
-## Rule Details
-
-### Fail
-
-```js
-import fs from 'fs';
-import path from 'path';
-
-var fs = require('fs');
-var path = require('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');
-
-/* eslint import/no-nodejs-modules: ["error", {"allow": ["path"]}] */
-import path from 'path';
-```
-
-## When Not To Use It
-
-If you have a project that is run mainly or partially using Node.js.

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

@@ -1,70 +0,0 @@
-# import/no-relative-packages
-
-🔧 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 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.
-
-## Examples
-
-Given the following folder structure:
-
-```pt
-my-project
-├── packages
-│   ├── foo
-│   │   ├── index.js
-│   │   └── package.json
-│   └── bar
-│       ├── index.js
-│       └── package.json
-└── entry.js
-```
-
-And the .eslintrc file:
-
-```json
-{
-  ...
-  "rules": {
-    "import/no-relative-packages": "error"
-  }
-}
-```
-
-The following patterns are considered problems:
-
-```js
-/**
- *  in my-project/packages/foo.js
- */
-
-import bar from '../bar'; // Import sibling package using relative path
-import entry from '../../entry.js'; // Import from parent package using relative path
-
-/**
- *  in my-project/entry.js
- */
-
-import bar from './packages/bar'; // Import child package using relative path
-```
-
-The following patterns are NOT considered problems:
-
-```js
-/**
- *  in my-project/packages/foo.js
- */
-
-import bar from 'bar'; // Import sibling package using package name
-
-/**
- *  in my-project/entry.js
- */
-
-import bar from 'bar'; // Import sibling package using package name
-```

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

@@ -1,123 +0,0 @@
-# import/no-relative-parent-imports
-
-<!-- end auto-generated rule header -->
-
-Use this rule to prevent imports to folders in relative parent paths.
-
-This rule is useful for enforcing tree-like folder structures instead of complex graph-like folder structures. While this restriction might be a departure from Node's default resolution style, it can lead large, complex codebases to be easier to maintain. If you've ever had debates over "where to put files" this rule is for you.
-
-To fix violations of this rule there are three general strategies. Given this example:
-
-```pt
-numbers
-└── three.js
-add.js
-```
-
-```js
-// ./add.js
-export default function (numbers) {
-  return numbers.reduce((sum, n) => sum + n, 0);
-}
-
-// ./numbers/three.js
-import add from '../add'; // violates import/no-relative-parent-imports
-
-export default function three() {
-  return add([1, 2]);
-}
-```
-
-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`:
-
-   ```pt
-   three.js
-   add.js
-   ```
-
-   or since `add` doesn't have any imports, it could be in it's own directory (namespace):
-
-   ```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]);
-   }
-
-   // 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]);
-   }
-   ```
-
-These are (respectively) static, dynamic & global solutions to graph-like dependency resolution.
-
-## Examples
-
-Given the following folder structure:
-
-```pt
-my-project
-├── lib
-│   ├── a.js
-│   └── b.js
-└── main.js
-```
-
-And the .eslintrc file:
-
-```json
-{
-  ...
-  "rules": {
-    "import/no-relative-parent-imports": "error"
-  }
-}
-```
-
-The following patterns are considered problems:
-
-```js
-/**
- *  in my-project/lib/a.js
- */
-
-import bar from '../main'; // Import parent file using a relative path
-```
-
-The following patterns are NOT considered problems:
-
-```js
-/**
- *  in my-project/main.js
- */
-
-import foo from 'foo'; // Import package using module path
-import a from './lib/a'; // Import child file using relative path
-
-/**
- *  in my-project/lib/a.js
- */
-
-import b from './b'; // Import sibling file using relative path
-```

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

@@ -1,198 +0,0 @@
-# import/no-restricted-paths
-
-<!-- end auto-generated rule header -->
-
-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.
-
-In order to prevent such scenarios this rule allows you to define restricted zones where you can forbid files from imported if they match a specific path.
-
-## Rule Details
-
-This rule has one option. The option is an object containing the definition of all restricted `zones` and the optional `basePath` which is used to resolve relative paths within.
-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.
-
-### Examples
-
-Given the following folder structure:
-
-```pt
-my-project
-├── client
-│   └── foo.js
-│   └── baz.js
-└── server
-    └── bar.js
-```
-
-and the current file being linted is `my-project/client/foo.js`.
-
-The following patterns are considered problems when configuration set to `{ "zones": [ { "target": "./client", "from": "./server" } ] }`:
-
-```js
-import bar from '../server/bar';
-```
-
-The following patterns are not considered problems when configuration set to `{ "zones": [ { "target": "./client", "from": "./server" } ] }`:
-
-```js
-import baz from '../client/baz';
-```
-
----------------
-
-Given the following folder structure:
-
-```pt
-my-project
-├── client
-│   └── foo.js
-│   └── baz.js
-└── server
-    ├── one
-    │   └── a.js
-    │   └── b.js
-    └── two
-```
-
-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",
-    "except": ["./one"]
-} ] }
-```
-
-The following pattern is considered a problem:
-
-```js
-import a from '../two/a'
-```
-
-The following pattern is not considered a problem:
-
-```js
-import b from './b'
-
-```
-
----------------
-
-Given the following folder structure:
-
-```pt
-my-project
-├── client
-    └── foo.js
-    └── sub-module
-        └── bar.js
-        └── baz.js
-
-```
-
-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/**/*",
-} ] }
-```
-
-The following import is considered a problem in `my-project/client/foo.js`:
-
-```js
-import a from './sub-module/baz'
-```
-
-The following import is not considered a problem in `my-project/client/sub-module/bar.js`:
-
-```js
-import b from './baz'
-```
-
----------------
-
-Given the following folder structure:
-
-```pt
-my-project
-└── one
-   └── a.js
-   └── b.js
-└── two
-   └── a.js
-   └── b.js
-└── three
-   └── a.js
-   └── b.js
-```
-
-and the current configuration is set to:
-
-```json
-{
-  "zones": [
-    {
-      "target": ["./tests/files/restricted-paths/two/*", "./tests/files/restricted-paths/three/*"],
-      "from": ["./tests/files/restricted-paths/one", "./tests/files/restricted-paths/three"],
-    }
-  ]
-}
-```
-
-The following patterns are not considered a problem in `my-project/one/b.js`:
-
-```js
-import a from '../three/a'
-```
-
-```js
-import a from './a'
-```
-
-The following pattern is not considered a problem in `my-project/two/b.js`:
-
-```js
-import a from './a'
-```
-
-The following patterns are considered a problem in `my-project/two/a.js`:
-
-```js
-import a from '../one/a'
-```
-
-```js
-import a from '../three/a'
-```
-
-The following patterns are considered a problem in `my-project/three/b.js`:
-
-```js
-import a from '../one/a'
-```
-
-```js
-import a from './a'
-```

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

@@ -1,32 +0,0 @@
-# import/no-self-import
-
-<!-- end auto-generated rule header -->
-
-Forbid a module from importing itself. This can sometimes happen during refactoring.
-
-## Rule Details
-
-### Fail
-
-```js
-// foo.js
-import foo from './foo';
-
-const foo = require('./foo');
-```
-
-```js
-// index.js
-import index from '.';
-
-const index = require('.');
-```
-
-### Pass
-
-```js
-// foo.js
-import bar from './bar';
-
-const bar = require('./bar');
-```

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

@@ -1,60 +0,0 @@
-# import/no-unassigned-import
-
-<!-- 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.
-
-This rule aims to remove modules with side-effects by reporting when a module is imported but not assigned.
-
-## Options
-
-This rule supports the following option:
-
-`allow`: An Array of globs. The files that match any of these patterns would be ignored/allowed by the linter. This can be useful for some build environments (e.g. css-loader in webpack).
-
-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
-import 'should'
-require('should')
-
-// In <PROJECT_ROOT>/src/app.js
-import '../styles/app.css'
-// {"allow": ["styles/*.css"]}
-```
-
-## Pass
-
-```js
-import _ from 'foo'
-import _, {foo} from 'foo'
-import _, {foo as bar} from 'foo'
-import {foo as bar} from 'foo'
-import * as _ from 'foo'
-
-const _ = require('foo')
-const {foo} = require('foo')
-const {foo: bar} = require('foo')
-const [a, b] = require('foo')
-const _ = require('foo')
-
-// Module is not assigned, but it is used
-bar(require('foo'))
-require('foo').bar
-require('foo').bar()
-require('foo')()
-
-// With allow option set
-import './style.css' // {"allow": ["**/*.css"]}
-import 'babel-register' // {"allow": ["babel-register"]}
-
-// In <PROJECT_ROOT>/src/app.js
-import './styles/app.css'
-import '../scripts/register.js'
-// {"allow": ["src/styles/**", "**/scripts/*.js"]}
-```

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

@@ -1,110 +0,0 @@
-# import/no-unresolved
-
-💼 This rule is enabled in the following configs: ❗ `errors`, ☑️ `recommended`.
-
-<!-- end auto-generated rule header -->
-
-Ensures an imported module can be resolved to a module on the local filesystem,
-as defined by standard Node `require.resolve` behavior.
-
-See [settings](../../README.md#settings) for customization options for the resolution (i.e.
-additional filetypes, `NODE_PATH`, etc.)
-
-This rule can also optionally report on unresolved modules in CommonJS `require('./foo')` calls and AMD `require(['./foo'], function (foo) {...})` and `define(['./foo'], function (foo) {...})`.
-
-To enable this, send `{ commonjs: true/false, amd: true/false }` as a rule option.
-Both are disabled by default.
-
-If you are using Webpack, see the section on [resolvers](../../README.md#resolvers).
-
-## Rule Details
-
-### Options
-
-By default, only ES6 imports will be resolved:
-
-```js
-/*eslint import/no-unresolved: 2*/
-import x from './foo' // reports if './foo' cannot be resolved on the filesystem
-```
-
-If `{commonjs: true}` is provided, single-argument `require` calls will be resolved:
-
-```js
-/*eslint import/no-unresolved: [2, { commonjs: true }]*/
-const { default: x } = require('./foo') // reported if './foo' is not found
-
-require(0) // ignored
-require(['x', 'y'], function (x, y) { /*...*/ }) // ignored
-```
-
-Similarly, if `{ amd: true }` is provided, dependency paths for `define` and `require`
-calls will be resolved:
-
-```js
-/*eslint import/no-unresolved: [2, { amd: true }]*/
-define(['./foo'], function (foo) { /*...*/ }) // reported if './foo' is not found
-require(['./foo'], function (foo) { /*...*/ }) // reported if './foo' is not found
-
-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
-define(['./foo'], function (foo) { /*...*/ }) // reported if './foo' is not found
-require(['./foo'], function (foo) { /*...*/ }) // reported if './foo' is not found
-```
-
-#### `ignore`
-
-This rule has its own ignore list, separate from [`import/ignore`]. This is because you may want to know whether a module can be located, regardless of whether it can be parsed for exports: `node_modules`, CoffeeScript files, etc. are all good to resolve properly, but will not be parsed if configured as such via [`import/ignore`].
-
-To suppress errors from files that may not be properly resolved by your [resolver settings](../../README.md#resolver-plugins), you may add an `ignore` key with an array of `RegExp` pattern strings:
-
-```js
-/*eslint import/no-unresolved: [2, { ignore: ['\\.img$'] }]*/
-
-import { x } from './mod' // may be reported, if not resolved to a module
-
-import coolImg from '../../img/coolImg.img' // will not be reported, even if not found
-```
-
-#### `caseSensitive`
-
-By default, this rule will report paths whose case do not match the underlying filesystem path, if the FS is not case-sensitive. To disable this behavior, set the `caseSensitive` option to `false`.
-
-```js
-/*eslint import/no-unresolved: [2, { caseSensitive: true (default) | false }]*/
-const { default: x } = require('./foo') // reported if './foo' is actually './Foo' and caseSensitive: true
-```
-
-#### `caseSensitiveStrict`
-
-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 }]*/
-
-// Absolute paths
-import Foo from `/Users/fOo/bar/file.js` // reported, /Users/foo/bar/file.js
-import Foo from `d:/fOo/bar/file.js` // reported, d:/foo/bar/file.js
-
-// Relative paths, cwd is Users/foo/
-import Foo from `./../fOo/bar/file.js` // reported
-```
-
-## When Not To Use It
-
-If you're using a module bundler other than Node or Webpack, you may end up with a lot of false positive reports of missing dependencies.
-
-## 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
-
-[`import/ignore`]: ../../README.md#importignore