create-packer 1.34.4 → 1.34.6

package/template/lib/react/node_modules/eslint-plugin-import/docs/rules/first.md

@@ -0,0 +1,75 @@
+# 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

package/template/lib/react/node_modules/eslint-plugin-import/docs/rules/group-exports.md

@@ -0,0 +1,118 @@
+# 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.

package/template/lib/react/node_modules/eslint-plugin-import/docs/rules/imports-first.md

@@ -0,0 +1,9 @@
+# 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).

package/template/lib/react/node_modules/eslint-plugin-import/docs/rules/max-dependencies.md

@@ -0,0 +1,70 @@
+# 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.

package/template/lib/react/node_modules/eslint-plugin-import/docs/rules/named.md

@@ -0,0 +1,102 @@
+# 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

package/template/lib/react/node_modules/eslint-plugin-import/docs/rules/namespace.md

@@ -0,0 +1,106 @@
+# 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

package/template/lib/react/node_modules/eslint-plugin-import/docs/rules/newline-after-import.md

@@ -0,0 +1,167 @@
+# 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.

package/template/lib/react/node_modules/eslint-plugin-import/docs/rules/no-absolute-path.md

@@ -0,0 +1,54 @@
+# 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`
+```