create-packer 1.34.4 → 1.34.6

package/template/lib/ts/node_modules/eslint-plugin-import/SECURITY.md

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

package/template/lib/ts/node_modules/eslint-plugin-import/config/electron.js

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

package/template/lib/ts/node_modules/eslint-plugin-import/config/errors.js

@@ -0,0 +1,14 @@
+/**
+ * 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,
+  },
+};

package/template/lib/ts/node_modules/eslint-plugin-import/config/react-native.js

@@ -0,0 +1,13 @@
+/**
+ * - 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'],
+      },
+    },
+  },
+};

package/template/lib/ts/node_modules/eslint-plugin-import/config/react.js

@@ -0,0 +1,18 @@
+/**
+ * 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 },
+  },
+
+};

package/template/lib/ts/node_modules/eslint-plugin-import/config/recommended.js

@@ -0,0 +1,28 @@
+/**
+ * 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,
+  },
+};

package/template/lib/ts/node_modules/eslint-plugin-import/config/stage-0.js

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

package/template/lib/ts/node_modules/eslint-plugin-import/config/typescript.js

@@ -0,0 +1,34 @@
+/**
+ * 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',
+  },
+};

package/template/lib/ts/node_modules/eslint-plugin-import/config/warnings.js

@@ -0,0 +1,12 @@
+/**
+ * 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,
+  },
+};

package/template/lib/ts/node_modules/eslint-plugin-import/docs/rules/consistent-type-specifier-style.md

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

package/template/lib/ts/node_modules/eslint-plugin-import/docs/rules/default.md

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

package/template/lib/ts/node_modules/eslint-plugin-import/docs/rules/dynamic-import-chunkname.md

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

package/template/lib/ts/node_modules/eslint-plugin-import/docs/rules/export.md

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

package/template/lib/ts/node_modules/eslint-plugin-import/docs/rules/exports-last.md

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

package/template/lib/ts/node_modules/eslint-plugin-import/docs/rules/extensions.md

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