@nr1e/commons 0.1.0 → 0.1.1-alpha.0

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-array-constructor.md

@@ -0,0 +1,35 @@
+---
+description: 'Disallow generic `Array` constructors.'
+---
+
+> 🛑 This file is source code, not the primary documentation location! 🛑
+>
+> See **https://typescript-eslint.io/rules/no-array-constructor** for documentation.
+
+## Examples
+
+This rule extends the base [`eslint/no-array-constructor`](https://eslint.org/docs/rules/no-array-constructor) rule.
+It adds support for the generically typed `Array` constructor (`new Array<Foo>()`).
+
+<!--tabs-->
+
+### ❌ Incorrect
+
+```ts
+/*eslint no-array-constructor: "error"*/
+
+Array(0, 1, 2);
+new Array(0, 1, 2);
+```
+
+### ✅ Correct
+
+```ts
+/*eslint no-array-constructor: "error"*/
+
+Array<number>(0, 1, 2);
+new Array<Foo>(x, y, z);
+
+Array(500);
+new Array(someOtherArray.length);
+```

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-base-to-string.md

@@ -0,0 +1,88 @@
+---
+description: 'Require `.toString()` to only be called on objects which provide useful information when stringified.'
+---
+
+> 🛑 This file is source code, not the primary documentation location! 🛑
+>
+> See **https://typescript-eslint.io/rules/no-base-to-string** for documentation.
+
+JavaScript will call `toString()` on an object when it is converted to a string, such as when `+` adding to a string or in `${}` template literals.
+The default Object `.toString()` returns `"[object Object]"`, which is often not what was intended.
+This rule reports on stringified values that aren't primitives and don't define a more useful `.toString()` method.
+
+> Note that `Function` provides its own `.toString()` that returns the function's code.
+> Functions are not flagged by this rule.
+
+## Examples
+
+<!--tabs-->
+
+### ❌ Incorrect
+
+```ts
+// Passing an object or class instance to string concatenation:
+'' + {};
+
+class MyClass {}
+const value = new MyClass();
+value + '';
+
+// Interpolation and manual .toString() calls too:
+`Value: ${value}`;
+({}.toString());
+```
+
+### ✅ Correct
+
+```ts
+// These types all have useful .toString()s
+'Text' + true;
+`Value: ${123}`;
+`Arrays too: ${[1, 2, 3]}`;
+(() => {}).toString();
+
+// Defining a custom .toString class is considered acceptable
+class CustomToString {
+  toString() {
+    return 'Hello, world!';
+  }
+}
+`Value: ${new CustomToString()}`;
+
+const literalWithToString = {
+  toString: () => 'Hello, world!',
+};
+
+`Value: ${literalWithToString}`;
+```
+
+## Options
+
+### `ignoredTypeNames`
+
+A string array of type names to ignore, this is useful for types missing `toString()` (but actually has `toString()`).
+There are some types missing `toString()` in old version TypeScript, like `RegExp`, `URL`, `URLSearchParams` etc.
+
+The following patterns are considered correct with the default options `{ ignoredTypeNames: ["RegExp"] }`:
+
+```ts
+`${/regex/}`;
+'' + /regex/;
+/regex/.toString();
+let value = /regex/;
+value.toString();
+let text = `${value}`;
+```
+
+## When Not To Use It
+
+If you don't mind `"[object Object]"` in your strings, then you will not need this rule.
+
+## Related To
+
+- [`restrict-plus-operands`](./restrict-plus-operands.md)
+- [`restrict-template-expressions`](./restrict-template-expressions.md)
+
+## Further Reading
+
+- [`Object.prototype.toString()` MDN documentation](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/toString)

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-confusing-non-null-assertion.md

@@ -0,0 +1,56 @@
+---
+description: 'Disallow non-null assertion in locations that may be confusing.'
+---
+
+> 🛑 This file is source code, not the primary documentation location! 🛑
+>
+> See **https://typescript-eslint.io/rules/no-confusing-non-null-assertion** for documentation.
+
+Using a non-null assertion (`!`) next to an assign or equals check (`=` or `==` or `===`) creates code that is confusing as it looks similar to a not equals check (`!=` `!==`).
+
+```typescript
+a! == b; // a non-null assertions(`!`) and an equals test(`==`)
+a !== b; // not equals test(`!==`)
+a! === b; // a non-null assertions(`!`) and an triple equals test(`===`)
+```
+
+This rule flags confusing `!` assertions and suggests either removing them or wrapping the asserted expression in `()` parenthesis.
+
+## Examples
+
+<!--tabs-->
+
+### ❌ Incorrect
+
+```ts
+interface Foo {
+  bar?: string;
+  num?: number;
+}
+
+const foo: Foo = getFoo();
+const isEqualsBar = foo.bar! == 'hello';
+const isEqualsNum = 1 + foo.num! == 2;
+```
+
+### ✅ Correct
+
+<!-- prettier-ignore -->
+```ts
+interface Foo {
+  bar?: string;
+  num?: number;
+}
+
+const foo: Foo = getFoo();
+const isEqualsBar = foo.bar == 'hello';
+const isEqualsNum = (1 + foo.num!) == 2;
+```
+
+## When Not To Use It
+
+If you don't care about this confusion, then you will not need this rule.
+
+## Further Reading
+
+- [`Issue: Easy misunderstanding: "! ==="`](https://github.com/microsoft/TypeScript/issues/37837) in [TypeScript repo](https://github.com/microsoft/TypeScript)

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-confusing-void-expression.md

@@ -0,0 +1,116 @@
+---
+description: 'Require expressions of type void to appear in statement position.'
+---
+
+> 🛑 This file is source code, not the primary documentation location! 🛑
+>
+> See **https://typescript-eslint.io/rules/no-confusing-void-expression** for documentation.
+
+`void` in TypeScript refers to a function return that is meant to be ignored.
+Attempting to use a `void`-typed value, such as storing the result of a called function in a variable, is often a sign of a programmer error.
+`void` can also be misleading for other developers even if used correctly.
+
+This rule prevents `void` type expressions from being used in misleading locations such as being assigned to a variable, provided as a function argument, or returned from a function.
+
+## Examples
+
+<!--tabs-->
+
+### ❌ Incorrect
+
+```ts
+// somebody forgot that `alert` doesn't return anything
+const response = alert('Are you sure?');
+console.log(alert('Are you sure?'));
+
+// it's not obvious whether the chained promise will contain the response (fixable)
+promise.then(value => window.postMessage(value));
+
+// it looks like we are returning the result of `console.error` (fixable)
+function doSomething() {
+  if (!somethingToDo) {
+    return console.error('Nothing to do!');
+  }
+
+  console.log('Doing a thing...');
+}
+```
+
+### ✅ Correct
+
+```ts
+// just a regular void function in a statement position
+alert('Hello, world!');
+
+// this function returns a boolean value so it's ok
+const response = confirm('Are you sure?');
+console.log(confirm('Are you sure?'));
+
+// now it's obvious that `postMessage` doesn't return any response
+promise.then(value => {
+  window.postMessage(value);
+});
+
+// now it's explicit that we want to log the error and return early
+function doSomething() {
+  if (!somethingToDo) {
+    console.error('Nothing to do!');
+    return;
+  }
+
+  console.log('Doing a thing...');
+}
+
+// using logical expressions for their side effects is fine
+cond && console.log('true');
+cond || console.error('false');
+cond ? console.log('true') : console.error('false');
+```
+
+## Options
+
+### `ignoreArrowShorthand`
+
+It might be undesirable to wrap every arrow function shorthand expression with braces.
+Especially when using Prettier formatter, which spreads such code across 3 lines instead of 1.
+
+Examples of additional **correct** code with this option enabled:
+
+```ts
+promise.then(value => window.postMessage(value));
+```
+
+### `ignoreVoidOperator`
+
+It might be preferable to only use some distinct syntax
+to explicitly mark the confusing but valid usage of void expressions.
+This option allows void expressions which are explicitly wrapped in the `void` operator.
+This can help avoid confusion among other developers as long as they are made aware of this code style.
+
+This option also changes the automatic fixes for common cases to use the `void` operator.
+It also enables a suggestion fix to wrap the void expression with `void` operator for every problem reported.
+
+Examples of additional **correct** code with this option enabled:
+
+```ts
+// now it's obvious that we don't expect any response
+promise.then(value => void window.postMessage(value));
+
+// now it's explicit that we don't want to return anything
+function doSomething() {
+  if (!somethingToDo) {
+    return void console.error('Nothing to do!');
+  }
+
+  console.log('Doing a thing...');
+}
+
+// we are sure that we want to always log `undefined`
+console.log(void alert('Hello, world!'));
+```
+
+## When Not To Use It
+
+The return type of a function can be inspected by going to its definition or hovering over it in an IDE.
+If you don't care about being explicit about the void type in actual code then don't use this rule.
+Also, if you prefer concise coding style then also don't use it.

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-dupe-class-members.md

@@ -0,0 +1,12 @@
+---
+description: 'Disallow duplicate class members.'
+---
+
+> 🛑 This file is source code, not the primary documentation location! 🛑
+>
+> See **https://typescript-eslint.io/rules/no-dupe-class-members** for documentation.
+
+## Examples
+
+This rule extends the base [`eslint/no-dupe-class-members`](https://eslint.org/docs/rules/no-dupe-class-members) rule.
+It adds support for TypeScript's method overload definitions.

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-duplicate-enum-values.md

@@ -0,0 +1,50 @@
+---
+description: 'Disallow duplicate enum member values.'
+---
+
+> 🛑 This file is source code, not the primary documentation location! 🛑
+>
+> See **https://typescript-eslint.io/rules/no-duplicate-enum-values** for documentation.
+
+Although TypeScript supports duplicate enum member values, people usually expect members to have unique values within the same enum. Duplicate values can lead to bugs that are hard to track down.
+
+## Examples
+
+This rule disallows defining an enum with multiple members initialized to the same value.
+
+> This rule only enforces on enum members initialized with string or number literals.
+> Members without an initializer or initialized with an expression are not checked by this rule.
+
+<!--tabs-->
+
+### ❌ Incorrect
+
+```ts
+enum E {
+  A = 0,
+  B = 0,
+}
+```
+
+```ts
+enum E {
+  A = 'A',
+  B = 'A',
+}
+```
+
+### ✅ Correct
+
+```ts
+enum E {
+  A = 0,
+  B = 1,
+}
+```
+
+```ts
+enum E {
+  A = 'A',
+  B = 'B',
+}
+```

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-duplicate-imports.md

@@ -0,0 +1,12 @@
+---
+description: 'Disallow duplicate imports.'
+---
+
+> 🛑 This file is source code, not the primary documentation location! 🛑
+>
+> See **https://typescript-eslint.io/rules/no-duplicate-imports** for documentation.
+
+:::danger Deprecated
+
+This rule has been deprecated in favour of the [`import/no-duplicates`](https://github.com/import-js/eslint-plugin-import/blob/HEAD/docs/rules/no-duplicates.md) rule.
+:::

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-duplicate-type-constituents.md

@@ -0,0 +1,61 @@
+---
+description: 'Disallow duplicate constituents of union or intersection types.'
+---
+
+> 🛑 This file is source code, not the primary documentation location! 🛑
+>
+> See **https://typescript-eslint.io/rules/no-duplicate-type-constituents** for documentation.
+
+TypeScript supports types ("constituents") within union and intersection types being duplicates of each other.
+However, developers typically expect each constituent to be unique within its intersection or union.
+Duplicate values make the code overly verbose and generally reduce readability.
+
+## Rule Details
+
+This rule disallows duplicate union or intersection constituents.
+We consider types to be duplicate if they evaluate to the same result in the type system.
+For example, given `type A = string` and `type T = string | A`, this rule would flag that `A` is the same type as `string`.
+
+<!--tabs-->
+
+### ❌ Incorrect
+
+```ts
+type T1 = 'A' | 'A';
+
+type T2 = A | A | B;
+
+type T3 = { a: string } & { a: string };
+
+type T4 = [1, 2, 3] | [1, 2, 3];
+
+type StringA = string;
+type StringB = string;
+type T5 = StringA | StringB;
+```
+
+### ✅ Correct
+
+```ts
+type T1 = 'A' | 'B';
+
+type T2 = A | B | C;
+
+type T3 = { a: string } & { b: string };
+
+type T4 = [1, 2, 3] | [1, 2, 3, 4];
+
+type StringA = string;
+type NumberB = number;
+type T5 = StringA | NumberB;
+```
+
+## Options
+
+### `ignoreIntersections`
+
+When set to true, duplicate checks on intersection type constituents are ignored.
+
+### `ignoreUnions`
+
+When set to true, duplicate checks on union type constituents are ignored.

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-dynamic-delete.md

@@ -0,0 +1,53 @@
+---
+description: 'Disallow using the `delete` operator on computed key expressions.'
+---
+
+> 🛑 This file is source code, not the primary documentation location! 🛑
+>
+> See **https://typescript-eslint.io/rules/no-dynamic-delete** for documentation.
+
+Deleting dynamically computed keys can be dangerous and in some cases not well optimized.
+Using the `delete` operator on keys that aren't runtime constants could be a sign that you're using the wrong data structures.
+Using `Object`s with added and removed keys can cause occasional edge case bugs, such as if a key is named `"hasOwnProperty"`.
+
+> Consider using a `Map` or `Set` if you’re storing collections of objects.
+
+## Examples
+
+<!--tabs-->
+
+### ❌ Incorrect
+
+```ts
+// Can be replaced with the constant equivalents, such as container.aaa
+delete container['aaa'];
+delete container['Infinity'];
+
+// Dynamic, difficult-to-reason-about lookups
+const name = 'name';
+delete container[name];
+delete container[name.toUpperCase()];
+```
+
+### ✅ Correct
+
+```ts
+const container: { [i: string]: number } = {
+  /* ... */
+};
+
+// Constant runtime lookups by string index
+delete container.aaa;
+
+// Constants that must be accessed by []
+delete container[7];
+delete container['-Infinity'];
+```
+
+## When Not To Use It
+
+When you know your keys are safe to delete, this rule can be unnecessary.
+Some environments such as older browsers might not support `Map` and `Set`.
+
+Do not consider this rule as performance advice before profiling your code's bottlenecks.
+Even repeated minor performance slowdowns likely do not significantly affect your application's general perceived speed.

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-empty-function.md

@@ -0,0 +1,88 @@
+---
+description: 'Disallow empty functions.'
+---
+
+> 🛑 This file is source code, not the primary documentation location! 🛑
+>
+> See **https://typescript-eslint.io/rules/no-empty-function** for documentation.
+
+## Examples
+
+This rule extends the base [`eslint/no-empty-function`](https://eslint.org/docs/rules/no-empty-function) rule.
+It adds support for handling TypeScript specific code that would otherwise trigger the rule.
+
+One example of valid TypeScript specific code that would otherwise trigger the `no-empty-function` rule is the use of [parameter properties](https://www.typescriptlang.org/docs/handbook/classes.html#parameter-properties) in constructor functions.
+
+## Options
+
+This rule adds the following options:
+
+```ts
+type AdditionalAllowOptionEntries =
+  | 'private-constructors'
+  | 'protected-constructors'
+  | 'decoratedFunctions'
+  | 'overrideMethods';
+
+type AllowOptionEntries =
+  | BaseNoEmptyFunctionAllowOptionEntries
+  | AdditionalAllowOptionEntries;
+
+interface Options extends BaseNoEmptyFunctionOptions {
+  allow?: Array<AllowOptionEntries>;
+}
+const defaultOptions: Options = {
+  ...baseNoEmptyFunctionDefaultOptions,
+  allow: [],
+};
+```
+
+### allow: `private-constructors`
+
+Examples of correct code for the `{ "allow": ["private-constructors"] }` option:
+
+```ts
+class Foo {
+  private constructor() {}
+}
+```
+
+### allow: `protected-constructors`
+
+Examples of correct code for the `{ "allow": ["protected-constructors"] }` option:
+
+```ts
+class Foo {
+  protected constructor() {}
+}
+```
+
+### allow: `decoratedFunctions`
+
+Examples of correct code for the `{ "allow": ["decoratedFunctions"] }` option:
+
+```ts
+@decorator()
+function foo() {}
+
+class Foo {
+  @decorator()
+  foo() {}
+}
+```
+
+### allow: `overrideMethods`
+
+Examples of correct code for the `{ "allow": ["overrideMethods"] }` option:
+
+```ts
+abstract class Base {
+  protected greet(): void {
+    console.log('Hello!');
+  }
+}
+
+class Foo extends Base {
+  protected override greet(): void {}
+}
+```

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-empty-interface.md

@@ -0,0 +1,70 @@
+---
+description: 'Disallow the declaration of empty interfaces.'
+---
+
+> 🛑 This file is source code, not the primary documentation location! 🛑
+>
+> See **https://typescript-eslint.io/rules/no-empty-interface** for documentation.
+
+An empty interface in TypeScript does very little: any non-nullable value is assignable to `{}`.
+Using an empty interface is often a sign of programmer error, such as misunderstanding the concept of `{}` or forgetting to fill in fields.
+
+This rule aims to ensure that only meaningful interfaces are declared in the code.
+
+## Examples
+
+<!--tabs-->
+
+### ❌ Incorrect
+
+```ts
+// an empty interface
+interface Foo {}
+
+// an interface with only one supertype (Bar === Foo)
+interface Bar extends Foo {}
+
+// an interface with an empty list of supertypes
+interface Baz {}
+```
+
+### ✅ Correct
+
+```ts
+// an interface with any number of members
+interface Foo {
+  name: string;
+}
+
+// same as above
+interface Bar {
+  age: number;
+}
+
+// an interface with more than one supertype
+// in this case the interface can be used as a replacement of an intersection type.
+interface Baz extends Foo, Bar {}
+```
+
+<!--/tabs-->
+
+## Options
+
+This rule accepts a single object option with the following default configuration:
+
+```json
+{
+  "@typescript-eslint/no-empty-interface": [
+    "error",
+    {
+      "allowSingleExtends": false
+    }
+  ]
+}
+```
+
+- `allowSingleExtends: true` will silence warnings about extending a single interface without adding additional members
+
+## When Not To Use It
+
+If you don't care about having empty/meaningless interfaces, then you will not need this rule.