repoburg 1.0.31 → 1.0.33

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

@@ -1,29 +0,0 @@
----
-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.
-
-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
-Array(0, 1, 2);
-new Array(0, 1, 2);
-```
-
-### ✅ Correct
-
-```ts
-Array<number>(0, 1, 2);
-new Array<Foo>(x, y, z);
-
-Array(500);
-new Array(someOtherArray.length);
-```

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

@@ -1,40 +0,0 @@
----
-description: 'Disallow using the `delete` operator on array values.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/no-array-delete** for documentation.
-
-When using the `delete` operator with an array value, the array's `length` property is not affected,
-but the element at the specified index is removed and leaves an empty slot in the array.
-This is likely to lead to unexpected behavior. As mentioned in the
-[MDN documentation](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/delete#deleting_array_elements),
-the recommended way to remove an element from an array is by using the
-[`Array#splice`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/splice) method.
-
-## Examples
-
-<!--tabs-->
-
-### ❌ Incorrect
-
-```ts
-declare const arr: number[];
-
-delete arr[0];
-```
-
-### ✅ Correct
-
-```ts
-declare const arr: number[];
-
-arr.splice(0, 1);
-```
-
-<!--/tabs-->
-
-## When Not To Use It
-
-When you want to allow the delete operator with array expressions.

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

@@ -1,88 +0,0 @@
----
-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 option='{ "ignoredTypeNames": ["RegExp"] }' showPlaygroundButton
-`${/regex/}`;
-'' + /regex/;
-/regex/.toString();
-let value = /regex/;
-value.toString();
-let text = `${value}`;
-```
-
-## When Not To Use It
-
-If you don't mind a risk of `"[object Object]"` or incorrect type coercions in your values, 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/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-confusing-non-null-assertion.md

@@ -1,56 +0,0 @@
----
-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/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-confusing-void-expression.md

@@ -1,116 +0,0 @@
----
-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 option='{ "ignoreArrowShorthand": true }' showPlaygroundButton
-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 option='{ "ignoreVoidOperator": true }' showPlaygroundButton
-// 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 strongly prefer a concise coding style more strongly than any fear of `void`-related bugs then you can avoid this rule.

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

@@ -1,14 +0,0 @@
----
-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.
-
-import TypeScriptOverlap from "@site/src/components/TypeScriptOverlap";
-
-<TypeScriptOverlap />
-
-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/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-duplicate-enum-values.md

@@ -1,58 +0,0 @@
----
-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',
-}
-```
-
-## When Not To Use It
-
-It can sometimes be useful to include duplicate enum members for very specific use cases.
-For example, when renaming an enum member, it can sometimes be useful to keep the old name until a scheduled major breaking change.
-You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.
-
-In general, if your project intentionally duplicates enum member values, you can avoid this rule.

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

@@ -1,13 +0,0 @@
-:::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.
-
-:::
-
-<!--
-This doc file has been left on purpose because `import/no-duplicates` is
-commonly requested. This exists to help direct people to the replacement rule.
-
-Note that there is no actual way to get to this page in the normal navigation,
-so end-users will only be able to get to this page from the search bar.
--->

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

@@ -1,66 +0,0 @@
----
-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.
-
-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.
-
-## When Not To Use It
-
-It can sometimes be useful for the sake of documentation to include aliases for the same type.
-You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.
-
-> In some of those cases, [branded types](https://basarat.gitbook.io/typescript/main-1/nominaltyping#using-interfaces) might be a type-safe way to represent the underlying data types.

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

@@ -1,53 +0,0 @@
----
-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.
-You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.
-
-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/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-empty-function.md

@@ -1,92 +0,0 @@
----
-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.
-
-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 option='{ "allow": ["private-constructors"] }' showPlaygroundButton
-class Foo {
-  private constructor() {}
-}
-```
-
-### allow: `protected-constructors`
-
-Examples of correct code for the `{ "allow": ["protected-constructors"] }` option:
-
-```ts option='{ "allow": ["protected-constructors"] }' showPlaygroundButton
-class Foo {
-  protected constructor() {}
-}
-```
-
-### allow: `decoratedFunctions`
-
-Examples of correct code for the `{ "allow": ["decoratedFunctions"] }` option:
-
-```ts option='{ "allow": ["decoratedFunctions"] }' showPlaygroundButton
-class Foo {
-  @decorator()
-  foo() {}
-}
-```
-
-### allow: `overrideMethods`
-
-Examples of correct code for the `{ "allow": ["overrideMethods"] }` option:
-
-```ts option='{ "allow": ["overrideMethods"] }' showPlaygroundButton
-abstract class Base {
-  protected greet(): void {
-    console.log('Hello!');
-  }
-}
-
-class Foo extends Base {
-  protected override greet(): void {}
-}
-```
-
-## When Not To Use It
-
-If you are working with external APIs that require functions even if they do nothing, then you may want to avoid this rule.
-You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.
-
-Test code often violates this rule as well.
-If your testing setup doesn't support "mock" or "spy" functions such as [`jest.fn()`](https://jestjs.io/docs/mock-functions), [`sinon.spy()`](https://sinonjs.org/releases/latest/spies), or [`vi.fn()`](https://vitest.dev/guide/mocking.html), you may wish to disable this rule in test files.
-Again, if those cases aren't extremely common, you might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule in test files.

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

@@ -1,59 +0,0 @@
----
-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
-
-### `allowSingleExtends`
-
-`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.