RubyGems - immosquare-cleaner - Versions diffs - 0.1.34 → 0.1.35 - Mend

immosquare-cleaner 0.1.34 → 0.1.35

Files changed (191) hide show

data/node_modules/eslint-plugin-import/docs/rules/no-extraneous-dependencies.md DELETED Viewed

@@ -1,139 +0,0 @@
-# import/no-extraneous-dependencies
-<!-- end auto-generated rule header -->
-Forbid the import of external modules that are not declared in the `package.json`'s `dependencies`, `devDependencies`, `optionalDependencies`, `peerDependencies`, or `bundledDependencies`.
-The closest parent `package.json` will be used. If no `package.json` is found, the rule will not lint anything. This behavior can be changed with the rule option `packageDir`. Normally ignores imports of modules marked internal, but this can be changed with the rule option `includeInternal`. Type imports can be verified by specifying `includeTypes`.
-Modules have to be installed for this rule to work.
-## Options
-This rule supports the following options:
-`devDependencies`: If set to `false`, then the rule will show an error when `devDependencies` are imported. Defaults to `true`.
-Type imports are ignored by default.
-`optionalDependencies`: If set to `false`, then the rule will show an error when `optionalDependencies` are imported. Defaults to `true`.
-`peerDependencies`: If set to `false`, then the rule will show an error when `peerDependencies` are imported. Defaults to `true`.
-`bundledDependencies`: If set to `false`, then the rule will show an error when `bundledDependencies` are imported. Defaults to `true`.
-You can set the options like this:
-```js
-"import/no-extraneous-dependencies": ["error", {"devDependencies": false, "optionalDependencies": false, "peerDependencies": false}]
-```
-You can also use an array of globs instead of literal booleans:
-```js
-"import/no-extraneous-dependencies": ["error", {"devDependencies": ["**/*.test.js", "**/*.spec.js"]}]
-```
-When using an array of globs, the setting will be set to `true` (no errors reported) if the name of the file being linted matches a single glob in the array, and `false` otherwise.
-There are 2 boolean options to opt into checking extra imports that are normally ignored: `includeInternal`, which enables the checking of internal modules, and `includeTypes`, which enables checking of type imports in TypeScript.
-```js
-"import/no-extraneous-dependencies": ["error", {"includeInternal": true, "includeTypes": true}]
-```
-Also there is one more option called `packageDir`, this option is to specify the path to the folder containing package.json.
-If provided as a relative path string, will be computed relative to the current working directory at linter execution time. If this is not ideal (does not work with some editor integrations), consider using `__dirname` to provide a path relative to your configuration.
-```js
-"import/no-extraneous-dependencies": ["error", {"packageDir": './some-dir/'}]
-// or
-"import/no-extraneous-dependencies": ["error", {"packageDir": path.join(__dirname, 'some-dir')}]
-```
-It may also be an array of multiple paths, to support monorepos or other novel project
-folder layouts:
-```js
-"import/no-extraneous-dependencies": ["error", {"packageDir": ['./some-dir/', './root-pkg']}]
-```
-## Rule Details
-Given the following `package.json`:
-```json
-{
-  "name": "my-project",
-  "...": "...",
-  "dependencies": {
-    "builtin-modules": "^1.1.1",
-    "lodash.cond": "^4.2.0",
-    "lodash.find": "^4.2.0",
-    "pkg-up": "^1.0.0"
-  },
-  "devDependencies": {
-    "ava": "^0.13.0",
-    "eslint": "^2.4.0",
-    "eslint-plugin-ava": "^1.3.0",
-    "xo": "^0.13.0"
-  },
-  "optionalDependencies": {
-    "lodash.isarray": "^4.0.0"
-  },
-  "peerDependencies": {
-    "react": ">=15.0.0 <16.0.0"
-  },
-  "bundledDependencies": [
-    "@generated/foo",
-  ]
-}
-```
-## Fail
-```js
-var _ = require('lodash');
-import _ from 'lodash';
-import react from 'react';
-/* eslint import/no-extraneous-dependencies: ["error", {"devDependencies": false}] */
-import test from 'ava';
-var test = require('ava');
-/* eslint import/no-extraneous-dependencies: ["error", {"optionalDependencies": false}] */
-import isArray from 'lodash.isarray';
-var isArray = require('lodash.isarray');
-/* eslint import/no-extraneous-dependencies: ["error", {"bundledDependencies": false}] */
-import foo from '"@generated/foo"';
-var foo = require('"@generated/foo"');
-/* eslint import/no-extraneous-dependencies: ["error", {"includeInternal": true}] */
-import foo from './foo';
-var foo = require('./foo');
-/* eslint import/no-extraneous-dependencies: ["error", {"includeTypes": true}] */
-import type { MyType } from 'foo';
-```
-## Pass
-```js
-// Builtin and internal modules are fine
-var path = require('path');
-var foo = require('./foo');
-import test from 'ava';
-import find from 'lodash.find';
-import isArray from 'lodash.isarray';
-import foo from '"@generated/foo"';
-import type { MyType } from 'foo';
-/* eslint import/no-extraneous-dependencies: ["error", {"peerDependencies": true}] */
-import react from 'react';
-```
-## When Not To Use It
-If you do not have a `package.json` file in your project.

data/node_modules/eslint-plugin-import/docs/rules/no-import-module-exports.md DELETED Viewed

@@ -1,81 +0,0 @@
-# import/no-import-module-exports
-🔧 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 the use of import declarations with CommonJS exports in any module
-except for the [main module](https://docs.npmjs.com/files/package.json#main).
-If you have multiple entry points or are using `js:next` this rule includes an
-`exceptions` option which you can use to exclude those files from the rule.
-## Options
-### `exceptions`
- - An array of globs. The rule will be omitted from any file that matches a glob
-   in the options array. For example, the following setting will omit the rule
-   in the `some-file.js` file.
-```json
-"import/no-import-module-exports": ["error", {
-    "exceptions": ["**/*/some-file.js"]
-}]
-```
-## Rule Details
-### Fail
-```js
-import { stuff } from 'starwars'
-module.exports = thing
-import * as allThings from 'starwars'
-exports.bar = thing
-import thing from 'other-thing'
-exports.foo = bar
-import thing from 'starwars'
-const baz = module.exports = thing
-console.log(baz)
-```
-### Pass
-Given the following package.json:
-```json
-{
-  "main": "lib/index.js",
-}
-```
-```js
-import thing from 'other-thing'
-export default thing
-const thing = require('thing')
-module.exports = thing
-const thing = require('thing')
-exports.foo = bar
-import thing from 'otherthing'
-console.log(thing.module.exports)
-// in lib/index.js
-import foo from 'path';
-module.exports = foo;
-// in some-file.js
-// eslint import/no-import-module-exports: ["error", {"exceptions": ["**/*/some-file.js"]}]
-import foo from 'path';
-module.exports = foo;
-```
-### Further Reading
- - [webpack issue #4039](https://github.com/webpack/webpack/issues/4039)

data/node_modules/eslint-plugin-import/docs/rules/no-internal-modules.md DELETED Viewed

@@ -1,136 +0,0 @@
-# import/no-internal-modules
-<!-- end auto-generated rule header -->
-Use this rule to prevent importing the submodules of other modules.
-## Rule Details
-This rule has two mutally exclusive options that are arrays of [minimatch/glob patterns](https://github.com/isaacs/node-glob#glob-primer) patterns:
- - `allow` that include paths and import statements that can be imported with reaching.
- - `forbid` that exclude paths and import statements that can be imported with reaching.
-### Examples
-Given the following folder structure:
-```pt
-my-project
-├── actions
-│   └── getUser.js
-│   └── updateUser.js
-├── reducer
-│   └── index.js
-│   └── user.js
-├── redux
-│   └── index.js
-│   └── configureStore.js
-└── app
-│   └── index.js
-│   └── settings.js
-└── entry.js
-```
-And the .eslintrc file:
-```json
-{
-  ...
-  "rules": {
-    "import/no-internal-modules": [ "error", {
-      "allow": [ "**/actions/*", "source-map-support/*" ],
-    } ]
-  }
-}
-```
-The following patterns are considered problems:
-```js
-/**
- *  in my-project/entry.js
- */
-import { settings } from './app/index'; // Reaching to "./app/index" is not allowed
-import userReducer from './reducer/user'; // Reaching to "./reducer/user" is not allowed
-import configureStore from './redux/configureStore'; // Reaching to "./redux/configureStore" is not allowed
-export { settings } from './app/index'; // Reaching to "./app/index" is not allowed
-export * from './reducer/user'; // Reaching to "./reducer/user" is not allowed
-```
-The following patterns are NOT considered problems:
-```js
-/**
- *  in my-project/entry.js
- */
-import 'source-map-support/register';
-import { settings } from '../app';
-import getUser from '../actions/getUser';
-export * from 'source-map-support/register';
-export { settings } from '../app';
-```
-Given the following folder structure:
-```pt
-my-project
-├── actions
-│   └── getUser.js
-│   └── updateUser.js
-├── reducer
-│   └── index.js
-│   └── user.js
-├── redux
-│   └── index.js
-│   └── configureStore.js
-└── app
-│   └── index.js
-│   └── settings.js
-└── entry.js
-```
-And the .eslintrc file:
-```json
-{
-  ...
-  "rules": {
-    "import/no-internal-modules": [ "error", {
-      "forbid": [ "**/actions/*", "source-map-support/*" ],
-    } ]
-  }
-}
-```
-The following patterns are considered problems:
-```js
-/**
- *  in my-project/entry.js
- */
-import 'source-map-support/register';
-import getUser from '../actions/getUser';
-export * from 'source-map-support/register';
-export getUser from '../actions/getUser';
-```
-The following patterns are NOT considered problems:
-```js
-/**
- *  in my-project/entry.js
- */
-import 'source-map-support';
-import { getUser } from '../actions';
-export * from 'source-map-support';
-export { getUser } from '../actions';
-```

data/node_modules/eslint-plugin-import/docs/rules/no-mutable-exports.md DELETED Viewed

@@ -1,54 +0,0 @@
-# import/no-mutable-exports
-<!-- end auto-generated rule header -->
-Forbids the use of mutable exports with `var` or `let`.
-## Rule Details
-Valid:
-```js
-export const count = 1
-export function getCount() {}
-export class Counter {}
-```
-...whereas here exports will be reported:
-```js
-export let count = 2
-export var count = 3
-let count = 4
-export { count } // reported here
-```
-## Functions/Classes
-Note that exported function/class declaration identifiers may be reassigned,
-but are not flagged by this rule at this time. They may be in the future, if a
-reassignment is detected, i.e.
-```js
-// possible future behavior!
-export class Counter {} // reported here: exported class is reassigned on line [x].
-Counter = KitchenSink // not reported here unless you enable no-class-assign
-// this pre-declaration reassignment is valid on account of function hoisting
-getCount = function getDuke() {} // not reported here without no-func-assign
-export function getCount() {} // reported here: exported function is reassigned on line [x].
-```
-To prevent general reassignment of these identifiers, exported or not, you may
-want to enable the following core ESLint rules:
- - [no-func-assign]
- - [no-class-assign]
-[no-func-assign]: https://eslint.org/docs/rules/no-func-assign
-[no-class-assign]: https://eslint.org/docs/rules/no-class-assign
-## When Not To Use It
-If your environment correctly implements mutable export bindings.

data/node_modules/eslint-plugin-import/docs/rules/no-named-as-default-member.md DELETED Viewed

@@ -1,52 +0,0 @@
-# import/no-named-as-default-member
-⚠️ This rule _warns_ in the following configs: ☑️ `recommended`, 🚸 `warnings`.
-<!-- end auto-generated rule header -->
-Reports use of an exported name as a property on the default export.
-Rationale: Accessing a property that has a name that is shared by an exported
-name from the same module is likely to be a mistake.
-Named import syntax looks very similar to destructuring assignment. It's easy to
-make the (incorrect) assumption that named exports are also accessible as
-properties of the default export.
-Furthermore, [in Babel 5 this is actually how things worked][blog]. This was
-fixed in Babel 6. Before upgrading an existing codebase to Babel 6, it can be
-useful to run this lint rule.
-[blog]: https://kentcdodds.com/blog/misunderstanding-es6-modules-upgrading-babel-tears-and-a-solution
-## Rule Details
-Given:
-```js
-// foo.js
-export default 'foo';
-export const bar = 'baz';
-```
-...this would be valid:
-```js
-import foo, {bar} from './foo.js';
-```
-...and the following would be reported:
-```js
-// Caution: `foo` also has a named export `bar`.
-// Check if you meant to write `import {bar} from './foo.js'` instead.
-import foo from './foo.js';
-const bar = foo.bar;
-```
-```js
-// Caution: `foo` also has a named export `bar`.
-// Check if you meant to write `import {bar} from './foo.js'` instead.
-import foo from './foo.js';
-const {bar} = foo;
-```

data/node_modules/eslint-plugin-import/docs/rules/no-named-as-default.md DELETED Viewed

@@ -1,53 +0,0 @@
-# import/no-named-as-default
-⚠️ This rule _warns_ in the following configs: ☑️ `recommended`, 🚸 `warnings`.
-<!-- end auto-generated rule header -->
-Reports use of an exported name as the locally imported name of a default export.
-Rationale: using an exported name as the name of the default export is likely...
- - _misleading_: others familiar with `foo.js` probably expect the name to be `foo`
- - _a mistake_: only needed to import `bar` and forgot the brackets (the case that is prompting this)
-## Rule Details
-Given:
-```js
-// foo.js
-export default 'foo';
-export const bar = 'baz';
-```
-...this would be valid:
-```js
-import foo from './foo.js';
-```
-...and this would be reported:
-```js
-// message: Using exported name 'bar' as identifier for default export.
-import bar from './foo.js';
-```
-For post-ES2015 `export` extensions, this also prevents exporting the default from a referenced module as a name within that module, for the same reasons:
-```js
-// valid:
-export foo from './foo.js';
-// message: Using exported name 'bar' as identifier for default export.
-export bar from './foo.js';
-```
-## Further Reading
- - ECMAScript Proposal: [export ns from]
- - ECMAScript Proposal: [export default from]
-[export ns from]: https://github.com/leebyron/ecmascript-export-ns-from
-[export default from]: https://github.com/leebyron/ecmascript-export-default-from

data/node_modules/eslint-plugin-import/docs/rules/no-named-default.md DELETED Viewed

@@ -1,36 +0,0 @@
-# import/no-named-default
-<!-- end auto-generated rule header -->
-Reports use of a default export as a locally named import.
-Rationale: the syntax exists to import default exports expressively, let's use it.
-Note that type imports, as used by [Flow], are always ignored.
-[Flow]: https://flow.org/
-## Rule Details
-Given:
-```js
-// foo.js
-export default 'foo';
-export const bar = 'baz';
-```
-...these would be valid:
-```js
-import foo from './foo.js';
-import foo, { bar } from './foo.js';
-```
-...and these would be reported:
-```js
-// message: Using exported name 'bar' as identifier for default export.
-import { default as foo } from './foo.js';
-import { default as foo, bar } from './foo.js';
-```

data/node_modules/eslint-plugin-import/docs/rules/no-named-export.md DELETED Viewed

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

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

@@ -1,44 +0,0 @@
-# import/no-namespace
-🔧 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 of not using namespace (a.k.a. "wildcard" `*`) imports.
-The rule is auto-fixable when the namespace object is only used for direct member access, e.g. `namespace.a`.
-## Options
-This rule supports the following options:
- - `ignore`: array of glob strings for modules that should be ignored by the rule.
-## Rule Details
-Valid:
-```js
-import defaultExport from './foo'
-import { a, b }  from './bar'
-import defaultExport, { a, b }  from './foobar'
-```
-```js
-/* eslint import/no-namespace: ["error", {ignore: ['*.ext']}] */
-import * as bar from './ignored-module.ext';
-```
-Invalid:
-```js
-import * as foo from 'foo';
-```
-```js
-import defaultExport, * as foo from 'foo';
-```
-## When Not To Use It
-If you want to use namespaces, you don't want to use this rule.