immosquare-cleaner 0.1.34 → 0.1.35

data/node_modules/eslint-plugin-import/SECURITY.md

@@ -1,11 +0,0 @@
-# Security Policy
-
-## Supported Versions
-
-Latest major/minor version is supported only for security updates.
-
-## Reporting a Vulnerability
-
-To report a security vulnerability, please use the
-[Tidelift security contact](https://tidelift.com/security).
-Tidelift will coordinate the fix and disclosure.

data/node_modules/eslint-plugin-import/config/electron.js

@@ -1,8 +0,0 @@
-/**
- * Default settings for Electron applications.
- */
-module.exports = {
-  settings: {
-    'import/core-modules': ['electron'],
-  },
-};

data/node_modules/eslint-plugin-import/config/errors.js

@@ -1,14 +0,0 @@
-/**
- * unopinionated config. just the things that are necessarily runtime errors
- * waiting to happen.
- * @type {Object}
- */
-module.exports = {
-  plugins: ['import'],
-  rules: { 'import/no-unresolved': 2,
-    'import/named': 2,
-    'import/namespace': 2,
-    'import/default': 2,
-    'import/export': 2,
-  },
-};

data/node_modules/eslint-plugin-import/config/react-native.js

@@ -1,13 +0,0 @@
-/**
- * - adds platform extensions to Node resolver
- */
-module.exports = {
-  settings: {
-    'import/resolver': {
-      node: {
-        // Note: will not complain if only _one_ of these files exists.
-        extensions: ['.js', '.web.js', '.ios.js', '.android.js'],
-      },
-    },
-  },
-};

data/node_modules/eslint-plugin-import/config/react.js

@@ -1,18 +0,0 @@
-/**
- * Adds `.jsx` as an extension, and enables JSX parsing.
- *
- * Even if _you_ aren't using JSX (or .jsx) directly, if your dependencies
- * define jsnext:main and have JSX internally, you may run into problems
- * if you don't enable these settings at the top level.
- */
-module.exports = {
-
-  settings: {
-    'import/extensions': ['.js', '.jsx'],
-  },
-
-  parserOptions: {
-    ecmaFeatures: { jsx: true },
-  },
-
-};

data/node_modules/eslint-plugin-import/config/recommended.js

@@ -1,28 +0,0 @@
-/**
- * The basics.
- * @type {Object}
- */
-module.exports = {
-  plugins: ['import'],
-
-  rules: {
-    // analysis/correctness
-    'import/no-unresolved': 'error',
-    'import/named': 'error',
-    'import/namespace': 'error',
-    'import/default': 'error',
-    'import/export': 'error',
-
-    // red flags (thus, warnings)
-    'import/no-named-as-default': 'warn',
-    'import/no-named-as-default-member': 'warn',
-    'import/no-duplicates': 'warn',
-  },
-
-  // need all these for parsing dependencies (even if _your_ code doesn't need
-  // all of them)
-  parserOptions: {
-    sourceType: 'module',
-    ecmaVersion: 2018,
-  },
-};

data/node_modules/eslint-plugin-import/config/stage-0.js

@@ -1,12 +0,0 @@
-/**
- * Rules in progress.
- *
- * Do not expect these to adhere to semver across releases.
- * @type {Object}
- */
-module.exports = {
-  plugins: ['import'],
-  rules: {
-    'import/no-deprecated': 1,
-  },
-};

data/node_modules/eslint-plugin-import/config/typescript.js

@@ -1,34 +0,0 @@
-/**
- * This config:
- * 1) adds `.jsx`, `.ts`, `.cts`, `.mts`, and `.tsx` as an extension
- * 2) enables JSX/TSX parsing
- */
-
-// Omit `.d.ts` because 1) TypeScript compilation already confirms that
-// types are resolved, and 2) it would mask an unresolved
-// `.ts`/`.tsx`/`.js`/`.jsx` implementation.
-const typeScriptExtensions = ['.ts', '.cts', '.mts', '.tsx'];
-
-const allExtensions = [...typeScriptExtensions, '.js', '.jsx'];
-
-module.exports = {
-  settings: {
-    'import/extensions': allExtensions,
-    'import/external-module-folders': ['node_modules', 'node_modules/@types'],
-    'import/parsers': {
-      '@typescript-eslint/parser': typeScriptExtensions,
-    },
-    'import/resolver': {
-      node: {
-        extensions: allExtensions,
-      },
-    },
-  },
-
-  rules: {
-    // analysis/correctness
-
-    // TypeScript compilation already ensures that named imports exist in the referenced module
-    'import/named': 'off',
-  },
-};

data/node_modules/eslint-plugin-import/config/warnings.js

@@ -1,12 +0,0 @@
-/**
- * more opinionated config.
- * @type {Object}
- */
-module.exports = {
-  plugins: ['import'],
-  rules: {
-    'import/no-named-as-default': 1,
-    'import/no-named-as-default-member': 1,
-    'import/no-duplicates': 1,
-  },
-};

data/node_modules/eslint-plugin-import/docs/rules/consistent-type-specifier-style.md

@@ -1,91 +0,0 @@
-# import/consistent-type-specifier-style
-
-🔧 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 -->
-
-In both Flow and TypeScript you can mark an import as a type-only import by adding a "kind" marker to the import. Both languages support two positions for marker.
-
-**At the top-level** which marks all names in the import as type-only and applies to named, default, and namespace (for TypeScript) specifiers:
-
-```ts
-import type Foo from 'Foo';
-import type {Bar} from 'Bar';
-// ts only
-import type * as Bam from 'Bam';
-// flow only
-import typeof Baz from 'Baz';
-```
-
-**Inline** with to the named import, which marks just the specific name in the import as type-only. An inline specifier is only valid for named specifiers, and not for default or namespace specifiers:
-
-```ts
-import {type Foo} from 'Foo';
-// flow only
-import {typeof Bar} from 'Bar';
-```
-
-## Rule Details
-
-This rule either enforces or bans the use of inline type-only markers for named imports.
-
-This rule includes a fixer that will automatically convert your specifiers to the correct form - however the fixer will not respect your preferences around de-duplicating imports. If this is important to you, consider using the [`import/no-duplicates`] rule.
-
-[`import/no-duplicates`]: ./no-duplicates.md
-
-## Options
-
-The rule accepts a single string option which may be one of:
-
- - `'prefer-inline'` - enforces that named type-only specifiers are only ever written with an inline marker; and never as part of a top-level, type-only import.
- - `'prefer-top-level'` - enforces that named type-only specifiers only ever written as part of a top-level, type-only import; and never with an inline marker.
-
-By default the rule will use the `prefer-inline` option.
-
-## Examples
-
-### `prefer-top-level`
-
-❌ Invalid with `["error", "prefer-top-level"]`
-
-```ts
-import {type Foo} from 'Foo';
-import Foo, {type Bar} from 'Foo';
-// flow only
-import {typeof Foo} from 'Foo';
-```
-
-✅ Valid with `["error", "prefer-top-level"]`
-
-```ts
-import type {Foo} from 'Foo';
-import type Foo, {Bar} from 'Foo';
-// flow only
-import typeof {Foo} from 'Foo';
-```
-
-### `prefer-inline`
-
-❌ Invalid with `["error", "prefer-inline"]`
-
-```ts
-import type {Foo} from 'Foo';
-import type Foo, {Bar} from 'Foo';
-// flow only
-import typeof {Foo} from 'Foo';
-```
-
-✅ Valid with `["error", "prefer-inline"]`
-
-```ts
-import {type Foo} from 'Foo';
-import Foo, {type Bar} from 'Foo';
-// flow only
-import {typeof Foo} from 'Foo';
-```
-
-## When Not To Use It
-
-If you aren't using Flow or TypeScript 4.5+, then this rule does not apply and need not be used.
-
-If you don't care about, and don't want to standardize how named specifiers are imported then you should not use this rule.

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

@@ -1,72 +0,0 @@
-# import/default
-
-💼 This rule is enabled in the following configs: ❗ `errors`, ☑️ `recommended`.
-
-<!-- end auto-generated rule header -->
-
-If a default import is requested, this rule will report if there is no default
-export in the imported module.
-
-For [ES7], reports if a default is named and exported but is not found in the
-referenced module.
-
-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
-
-Given:
-
-```js
-// ./foo.js
-export default function () { return 42 }
-
-// ./bar.js
-export function bar() { return null }
-
-// ./baz.js
-module.exports = function () { /* ... */ }
-
-// node_modules/some-module/index.js
-exports.sharedFunction = function shared() { /* ... */ }
-```
-
-The following is considered valid:
-
-```js
-import foo from './foo'
-
-// assuming 'node_modules' are ignored (true by default)
-import someModule from 'some-module'
-```
-
-...and the following cases are reported:
-
-```js
-import bar from './bar' // no default export found in ./bar
-import baz from './baz' // no default export found in ./baz
-```
-
-## 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.
-
-This rule currently does not interpret `module.exports = ...` as a `default` export,
-either, so such a situation will be reported in the importing module.
-
-## 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/dynamic-import-chunkname.md

@@ -1,92 +0,0 @@
-# import/dynamic-import-chunkname
-
-<!-- end auto-generated rule header -->
-
-This rule reports any dynamic imports without a webpackChunkName specified in a leading block comment in the proper format.
-
-This rule enforces naming of webpack chunks in dynamic imports. When you don't explicitly name chunks, webpack will autogenerate chunk names that are not consistent across builds, which prevents long-term browser caching.
-
-## Rule Details
-
-This rule runs against `import()` by default, but can be configured to also run against an alternative dynamic-import function, e.g. 'dynamicImport.'
-You can also configure the regex format you'd like to accept for the webpackChunkName - for example, if we don't want the number 6 to show up in our chunk names:
-
- ```javascript
-{
-  "dynamic-import-chunkname": [2, {
-    importFunctions: ["dynamicImport"],
-    webpackChunknameFormat: "[a-zA-Z0-57-9-/_]+"
-  }]
-}
-```
-
-### invalid
-
-The following patterns are invalid:
-
-```javascript
-// no leading comment
-import('someModule');
-
-// incorrectly formatted comment
-import(
-  /*webpackChunkName:"someModule"*/
-  'someModule',
-);
-import(
-  /* webpackChunkName : "someModule" */
-  'someModule',
-);
-
-// chunkname contains a 6 (forbidden by rule config)
-import(
-  /* webpackChunkName: "someModule6" */
-  'someModule',
-);
-
-// invalid syntax for webpack comment
-import(
-  /* totally not webpackChunkName: "someModule" */
-  'someModule',
-);
-
-// single-line comment, not a block-style comment
-import(
-  // webpackChunkName: "someModule"
-  'someModule',
-);
-```
-
-### valid
-
-The following patterns are valid:
-
-```javascript
-  import(
-    /* webpackChunkName: "someModule" */
-    'someModule',
-  );
-  import(
-    /* webpackChunkName: "someOtherModule12345789" */
-    'someModule',
-  );
-  import(
-    /* webpackChunkName: "someModule" */
-    /* webpackPrefetch: true */
-    'someModule',
-  );
-  import(
-    /* webpackChunkName: "someModule", webpackPrefetch: true */
-    'someModule',
-  );
-
-  // using single quotes instead of double quotes
-  import(
-    /* webpackChunkName: 'someModule' */
-    'someModule',
-  );
-```
-
-## When Not To Use It
-
-If you don't care that webpack will autogenerate chunk names and may blow up browser caches and bundle size reports.

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

@@ -1,37 +0,0 @@
-# import/export
-
-💼 This rule is enabled in the following configs: ❗ `errors`, ☑️ `recommended`.
-
-<!-- end auto-generated rule header -->
-
-Reports funny business with exports, like repeated exports of names or defaults.
-
-## Rule Details
-
-```js
-export default class MyClass { /*...*/ } // Multiple default exports.
-
-function makeClass() { return new MyClass(...arguments) }
-
-export default makeClass // Multiple default exports.
-```
-
-or
-
-```js
-export const foo = function () { /*...*/ } // Multiple exports of name 'foo'.
-
-function bar() { /*...*/ }
-export { bar as foo } // Multiple exports of name 'foo'.
-```
-
-In the case of named/default re-export, all `n` re-exports will be reported,
-as at least `n-1` of them are clearly mistakes, but it is not clear which one
-(if any) is intended. Could be the result of copy/paste, code duplication with
-intent to rename, etc.
-
-## Further Reading
-
- - Lee Byron's [ES7] export proposal
-
-[ES7]: https://github.com/leebyron/ecmascript-more-export-from

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

@@ -1,51 +0,0 @@
-# import/exports-last
-
-<!-- end auto-generated rule header -->
-
-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.
-
-## This will be reported
-
-```JS
-
-const bool = true
-
-export default bool
-
-const str = 'foo'
-
-```
-
-```JS
-
-export const bool = true
-
-const str = 'foo'
-
-```
-
-## This will not be reported
-
-```JS
-const arr = ['bar']
-
-export const bool = true
-
-export default bool
-
-export function func() {
-  console.log('Hello World 🌍')
-}
-
-export const str = 'foo'
-```
-
-## When Not To Use It
-
-If you don't mind exports being sprinkled throughout a file, you may not want to enable this rule.
-
-### ES6 exports only
-
-The exports-last rule is currently only working on ES6 exports. You may not want to enable this rule if you're using CommonJS exports.
-
-If you need CommonJS support feel free to open an issue or create a PR.

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

@@ -1,174 +0,0 @@
-# import/extensions
-
-<!-- end auto-generated rule header -->
-
-Some file resolve algorithms allow you to omit the file extension within the import source path. For example the `node` resolver (which does not yet support ESM/`import`) can resolve `./foo/bar` to the absolute path `/User/someone/foo/bar.js` because the `.js` extension is resolved automatically by default in CJS. Depending on the resolver you can configure more extensions to get resolved automatically.
-
-In order to provide a consistent use of file extensions across your code base, this rule can enforce or disallow the use of certain file extensions.
-
-## Rule Details
-
-This rule either takes one string option, one object option, or a string and an object option. If it is the string `"never"` (the default value), then the rule forbids the use for any extension. If it is the string `"always"`, then the rule enforces the use of extensions for all import statements. If it is the string `"ignorePackages"`, then the rule enforces the use of extensions for all import statements except package imports.
-
-```json
-"import/extensions": [<severity>, "never" | "always" | "ignorePackages"]
-```
-
-By providing an object you can configure each extension separately.
-
-```json
-"import/extensions": [<severity>, {
-  <extension>: "never" | "always" | "ignorePackages"
-}]
-```
-
- For example `{ "js": "always", "json": "never" }` would always enforce the use of the `.js` extension but never allow the use of the `.json` extension.
-
-By providing both a string and an object, the string will set the default setting for all extensions, and the object can be used to set granular overrides for specific extensions.
-
-```json
-"import/extensions": [
-  <severity>,
-  "never" | "always" | "ignorePackages",
-  {
-    <extension>: "never" | "always" | "ignorePackages"
-  }
-]
-```
-
-For example, `["error", "never", { "svg": "always" }]` would require that all extensions are omitted, except for "svg".
-
-`ignorePackages` can be set as a separate boolean option like this:
-
-```json
-"import/extensions": [
-  <severity>,
-  "never" | "always" | "ignorePackages",
-  {
-    ignorePackages: true | false,
-    pattern: {
-      <extension>: "never" | "always" | "ignorePackages"
-    }
-  }
-]
-```
-
-In that case, if you still want to specify extensions, you can do so inside the **pattern** property.
-Default value of `ignorePackages` is `false`.
-
-### Exception
-
-When disallowing the use of certain extensions this rule makes an exception and allows the use of extension when the file would not be resolvable without extension.
-
-For example, given the following folder structure:
-
-```pt
-├── foo
-│   ├── bar.js
-│   ├── bar.json
-```
-
-and this import statement:
-
-```js
-import bar from './foo/bar.json';
-```
-
-then the extension can’t be omitted because it would then resolve to `./foo/bar.js`.
-
-### Examples
-
-The following patterns are considered problems when configuration set to "never":
-
-```js
-import foo from './foo.js';
-
-import bar from './bar.json';
-
-import Component from './Component.jsx';
-
-import express from 'express/index.js';
-```
-
-The following patterns are not considered problems when configuration set to "never":
-
-```js
-import foo from './foo';
-
-import bar from './bar';
-
-import Component from './Component';
-
-import express from 'express/index';
-
-import * as path from 'path';
-```
-
-The following patterns are considered problems when configuration set to "always":
-
-```js
-import foo from './foo';
-
-import bar from './bar';
-
-import Component from './Component';
-
-import foo from '@/foo';
-```
-
-The following patterns are not considered problems when configuration set to "always":
-
-```js
-import foo from './foo.js';
-
-import bar from './bar.json';
-
-import Component from './Component.jsx';
-
-import * as path from 'path';
-
-import foo from '@/foo.js';
-```
-
-The following patterns are considered problems when configuration set to "ignorePackages":
-
-```js
-import foo from './foo';
-
-import bar from './bar';
-
-import Component from './Component';
-
-```
-
-The following patterns are not considered problems when configuration set to "ignorePackages":
-
-```js
-import foo from './foo.js';
-
-import bar from './bar.json';
-
-import Component from './Component.jsx';
-
-import express from 'express';
-
-import foo from '@/foo'
-```
-
-The following patterns are not considered problems when configuration set to `['error', 'always', {ignorePackages: true} ]`:
-
-```js
-import Component from './Component.jsx';
-
-import baz from 'foo/baz.js';
-
-import express from 'express';
-
-import foo from '@/foo';
-```
-
-## When Not To Use It
-
-If you are not concerned about a consistent usage of file extension.
-
-In the future, when this rule supports native node ESM resolution, and the plugin is configured to use native rather than transpiled ESM (a config option that is not yet available) - setting this to `always` will have no effect.