repoburg 1.3.98 → 1.3.100

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-misused-new.md

@@ -1,47 +0,0 @@
----
-description: 'Enforce valid definition of `new` and `constructor`.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/no-misused-new** for documentation.
-
-JavaScript classes may define a `constructor` method that runs when a class instance is newly created.
-TypeScript allows interfaces that describe a static class object to define a `new()` method (though this is rarely used in real world code).
-Developers new to JavaScript classes and/or TypeScript interfaces may sometimes confuse when to use `constructor` or `new`.
-
-This rule reports when a class defines a method named `new` or an interface defines a method named `constructor`.
-
-## Examples
-
-<!--tabs-->
-
-### ❌ Incorrect
-
-```ts
-declare class C {
-  new(): C;
-}
-
-interface I {
-  new (): I;
-  constructor(): void;
-}
-```
-
-### ✅ Correct
-
-```ts
-declare class C {
-  constructor();
-}
-
-interface I {
-  new (): C;
-}
-```
-
-## When Not To Use It
-
-If you intentionally want a class with a `new` method, and you're confident nobody working in your code will mistake it with a constructor, you might not want 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.

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-misused-promises.md

@@ -1,246 +0,0 @@
----
-description: 'Disallow Promises in places not designed to handle them.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/no-misused-promises** for documentation.
-
-This rule forbids providing Promises to logical locations such as if statements in places where the TypeScript compiler allows them but they are not handled properly.
-These situations can often arise due to a missing `await` keyword or just a misunderstanding of the way async
-functions are handled/awaited.
-
-:::tip
-`no-misused-promises` only detects code that provides Promises to incorrect _logical_ locations.
-See [`no-floating-promises`](./no-floating-promises.md) for detecting unhandled Promise _statements_.
-:::
-
-## Options
-
-### `checksConditionals`
-
-If you don't want to check conditionals, you can configure the rule with `"checksConditionals": false`:
-
-```json
-{
-  "@typescript-eslint/no-misused-promises": [
-    "error",
-    {
-      "checksConditionals": false
-    }
-  ]
-}
-```
-
-Doing so prevents the rule from looking at code like `if (somePromise)`.
-
-Examples of code for this rule with `checksConditionals: true`:
-
-<!--tabs-->
-
-#### ❌ Incorrect
-
-```ts option='{ "checksConditionals": true }'
-const promise = Promise.resolve('value');
-
-if (promise) {
-  // Do something
-}
-
-const val = promise ? 123 : 456;
-
-while (promise) {
-  // Do something
-}
-```
-
-#### ✅ Correct
-
-```ts option='{ "checksConditionals": true }'
-const promise = Promise.resolve('value');
-
-// Always `await` the Promise in a conditional
-if (await promise) {
-  // Do something
-}
-
-const val = (await promise) ? 123 : 456;
-
-while (await promise) {
-  // Do something
-}
-```
-
-<!--/tabs-->
-
-### `checksVoidReturn`
-
-Likewise, if you don't want to check functions that return promises where a void return is
-expected, your configuration will look like this:
-
-```json
-{
-  "@typescript-eslint/no-misused-promises": [
-    "error",
-    {
-      "checksVoidReturn": false
-    }
-  ]
-}
-```
-
-You can disable selective parts of the `checksVoidReturn` option by providing an object that disables specific checks.
-The following options are supported:
-
-- `arguments`: Disables checking an asynchronous function passed as argument where the parameter type expects a function that returns `void`
-- `attributes`: Disables checking an asynchronous function passed as a JSX attribute expected to be a function that returns `void`
-- `properties`: Disables checking an asynchronous function passed as an object property expected to be a function that returns `void`
-- `returns`: Disables checking an asynchronous function returned in a function whose return type is a function that returns `void`
-- `variables`: Disables checking an asynchronous function used as a variable whose return type is a function that returns `void`
-
-For example, if you don't mind that passing a `() => Promise<void>` to a `() => void` parameter or JSX attribute can lead to a floating unhandled Promise:
-
-```json
-{
-  "@typescript-eslint/no-misused-promises": [
-    "error",
-    {
-      "checksVoidReturn": {
-        "arguments": false,
-        "attributes": false
-      }
-    }
-  ]
-}
-```
-
-Examples of code for this rule with `checksVoidReturn: true`:
-
-<!--tabs-->
-
-#### ❌ Incorrect
-
-```ts option='{ "checksVoidReturn": true }'
-[1, 2, 3].forEach(async value => {
-  await doSomething(value);
-});
-
-new Promise(async (resolve, reject) => {
-  await doSomething();
-  resolve();
-});
-
-const eventEmitter = new EventEmitter();
-eventEmitter.on('some-event', async () => {
-  synchronousCall();
-  await doSomething();
-  otherSynchronousCall();
-});
-```
-
-#### ✅ Correct
-
-```ts option='{ "checksVoidReturn": true }'
-// for-of puts `await` in outer context
-for (const value of [1, 2, 3]) {
-  await doSomething(value);
-}
-
-// If outer context is not `async`, handle error explicitly
-Promise.all(
-  [1, 2, 3].map(async value => {
-    await doSomething(value);
-  }),
-).catch(handleError);
-
-// Use an async IIFE wrapper
-new Promise((resolve, reject) => {
-  // combine with `void` keyword to tell `no-floating-promises` rule to ignore unhandled rejection
-  void (async () => {
-    await doSomething();
-    resolve();
-  })();
-});
-
-// Name the async wrapper to call it later
-const eventEmitter = new EventEmitter();
-eventEmitter.on('some-event', () => {
-  const handler = async () => {
-    await doSomething();
-    otherSynchronousCall();
-  };
-
-  try {
-    synchronousCall();
-  } catch (err) {
-    handleSpecificError(err);
-  }
-
-  handler().catch(handleError);
-});
-```
-
-<!--/tabs-->
-
-### `checksSpreads`
-
-If you don't want to check object spreads, you can add this configuration:
-
-```json
-{
-  "@typescript-eslint/no-misused-promises": [
-    "error",
-    {
-      "checksSpreads": false
-    }
-  ]
-}
-```
-
-Examples of code for this rule with `checksSpreads: true`:
-
-<!--tabs-->
-
-#### ❌ Incorrect
-
-```ts option='{ "checksSpreads": true }'
-const getData = () => someAsyncOperation({ myArg: 'foo' });
-
-return { foo: 42, ...getData() };
-
-const getData2 = async () => {
-  await someAsyncOperation({ myArg: 'foo' });
-};
-
-return { foo: 42, ...getData2() };
-```
-
-#### ✅ Correct
-
-```ts option='{ "checksSpreads": true }'
-const getData = () => someAsyncOperation({ myArg: 'foo' });
-
-return { foo: 42, ...(await getData()) };
-
-const getData2 = async () => {
-  await someAsyncOperation({ myArg: 'foo' });
-};
-
-return { foo: 42, ...(await getData2()) };
-```
-
-<!--tabs-->
-
-## When Not To Use It
-
-This rule can be difficult to enable on large existing projects that set up many misused Promises.
-Alternately, if you're not worried about crashes from floating or misused Promises -such as if you have global unhandled Promise handlers registered- then in some cases it may be safe to not use 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.
-
-## Further Reading
-
-- [TypeScript void function assignability](https://github.com/Microsoft/TypeScript/wiki/FAQ#why-are-functions-returning-non-void-assignable-to-function-returning-void)
-
-## Related To
-
-- [`no-floating-promises`](./no-floating-promises.md)

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-mixed-enums.md

@@ -1,88 +0,0 @@
----
-description: 'Disallow enums from having both number and string members.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/no-mixed-enums** for documentation.
-
-TypeScript enums are allowed to assign numeric or string values to their members.
-Most enums contain either all numbers or all strings, but in theory you can mix-and-match within the same enum.
-Mixing enum member types is generally considered confusing and a bad practice.
-
-## Examples
-
-<!--tabs-->
-
-### ❌ Incorrect
-
-```ts
-enum Status {
-  Unknown,
-  Closed = 1,
-  Open = 'open',
-}
-```
-
-### ✅ Correct (Explicit Numbers)
-
-```ts
-enum Status {
-  Unknown = 0,
-  Closed = 1,
-  Open = 2,
-}
-```
-
-### ✅ Correct (Implicit Numbers)
-
-```ts
-enum Status {
-  Unknown,
-  Closed,
-  Open,
-}
-```
-
-### ✅ Correct (Strings)
-
-```ts
-enum Status {
-  Unknown = 'unknown',
-  Closed = 'closed',
-  Open = 'open',
-}
-```
-
-## Iteration Pitfalls of Mixed Enum Member Values
-
-Enum values may be iterated over using `Object.entries`/`Object.keys`/`Object.values`.
-
-If all enum members are strings, the number of items will match the number of enum members:
-
-```ts
-enum Status {
-  Closed = 'closed',
-  Open = 'open',
-}
-
-// ['closed', 'open']
-Object.values(Status);
-```
-
-But if the enum contains members that are initialized with numbers -including implicitly initialized numbers— then iteration over that enum will include those numbers as well:
-
-```ts
-enum Status {
-  Unknown,
-  Closed = 1,
-  Open = 'open',
-}
-
-// ["Unknown", "Closed", 0, 1, "open"]
-Object.values(Status);
-```
-
-## When Not To Use It
-
-If you don't mind the confusion of mixed enum member values and don't iterate over enums, you can safely disable this rule.

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

@@ -1,131 +0,0 @@
----
-description: 'Disallow TypeScript namespaces.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/no-namespace** for documentation.
-
-TypeScript historically allowed a form of code organization called "custom modules" (`module Example {}`), later renamed to "namespaces" (`namespace Example`).
-Namespaces are an outdated way to organize TypeScript code.
-ES2015 module syntax is now preferred (`import`/`export`).
-
-> This rule does not report on the use of TypeScript module declarations to describe external APIs (`declare module 'foo' {}`).
-
-## Examples
-
-Examples of code with the default options:
-
-<!--tabs-->
-
-### ❌ Incorrect
-
-```ts
-module foo {}
-namespace foo {}
-
-declare module foo {}
-declare namespace foo {}
-```
-
-### ✅ Correct
-
-```ts
-declare module 'foo' {}
-
-// anything inside a d.ts file
-```
-
-<!--/tabs-->
-
-## Options
-
-### `allowDeclarations`
-
-Examples of code with the `{ "allowDeclarations": true }` option:
-
-<!--tabs-->
-
-#### ❌ Incorrect
-
-```ts option='{ "allowDeclarations": true }'
-module foo {}
-namespace foo {}
-```
-
-#### ✅ Correct
-
-```ts option='{ "allowDeclarations": true }'
-declare module 'foo' {}
-declare module foo {}
-declare namespace foo {}
-
-declare global {
-  namespace foo {}
-}
-
-declare module foo {
-  namespace foo {}
-}
-```
-
-<!--/tabs-->
-
-Examples of code for the `{ "allowDeclarations": false }` option:
-
-<!--tabs-->
-
-#### ❌ Incorrect
-
-```ts option='{ "allowDeclarations": false }'
-module foo {}
-namespace foo {}
-declare module foo {}
-declare namespace foo {}
-```
-
-#### ✅ Correct
-
-```ts option='{ "allowDeclarations": false }'
-declare module 'foo' {}
-```
-
-### `allowDefinitionFiles`
-
-Examples of code for the `{ "allowDefinitionFiles": true }` option:
-
-<!--tabs-->
-
-#### ❌ Incorrect
-
-```ts option='{ "allowDefinitionFiles": true }'
-// if outside a d.ts file
-module foo {}
-namespace foo {}
-
-// if outside a d.ts file and allowDeclarations = false
-module foo {}
-namespace foo {}
-declare module foo {}
-declare namespace foo {}
-```
-
-#### ✅ Correct
-
-```ts option='{ "allowDefinitionFiles": true }'
-declare module 'foo' {}
-
-// anything inside a d.ts file
-```
-
-## When Not To Use It
-
-If your project was architected before modern modules and namespaces, it may be difficult to migrate off of namespaces.
-In that case you may not be able to use this rule for parts of your project.
-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.
-
-## Further Reading
-
-- [Modules](https://www.typescriptlang.org/docs/handbook/modules.html)
-- [Namespaces](https://www.typescriptlang.org/docs/handbook/namespaces.html)
-- [Namespaces and Modules](https://www.typescriptlang.org/docs/handbook/namespaces-and-modules.html)

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-non-null-asserted-nullish-coalescing.md

@@ -1,54 +0,0 @@
----
-description: 'Disallow non-null assertions in the left operand of a nullish coalescing operator.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/no-non-null-asserted-nullish-coalescing** for documentation.
-
-The `??` nullish coalescing runtime operator allows providing a default value when dealing with `null` or `undefined`.
-Using a `!` non-null assertion type operator in the left operand of a nullish coalescing operator is redundant, and likely a sign of programmer error or confusion over the two operators.
-
-## Examples
-
-<!--tabs-->
-
-### ❌ Incorrect
-
-```ts
-foo! ?? bar;
-foo.bazz! ?? bar;
-foo!.bazz! ?? bar;
-foo()! ?? bar;
-
-let x!: string;
-x! ?? '';
-
-let x: string;
-x = foo();
-x! ?? '';
-```
-
-### ✅ Correct
-
-```ts
-foo ?? bar;
-foo ?? bar!;
-foo!.bazz ?? bar;
-foo!.bazz ?? bar!;
-foo() ?? bar;
-
-// This is considered correct code because there's no way for the user to satisfy it.
-let x: string;
-x! ?? '';
-```
-
-## When Not To Use It
-
-If your project's types don't yet fully describe whether certain values may be nullable, such as if you're transitioning to `strictNullChecks`, this rule might create many false reports.
-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.
-
-## Further Reading
-
-- [TypeScript 3.7 Release Notes](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html)
-- [Nullish Coalescing Proposal](https://github.com/tc39/proposal-nullish-coalescing)

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-non-null-asserted-optional-chain.md

@@ -1,40 +0,0 @@
----
-description: 'Disallow non-null assertions after an optional chain expression.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/no-non-null-asserted-optional-chain** for documentation.
-
-`?.` optional chain expressions provide `undefined` if an object is `null` or `undefined`.
-Using a `!` non-null assertion to assert the result of an `?.` optional chain expression is non-nullable is likely wrong.
-
-> Most of the time, either the object was not nullable and did not need the `?.` for its property lookup, or the `!` is incorrect and introducing a type safety hole.
-
-## Examples
-
-<!--tabs-->
-
-### ❌ Incorrect
-
-```ts
-foo?.bar!;
-foo?.bar()!;
-```
-
-### ✅ Correct
-
-```ts
-foo?.bar;
-foo?.bar();
-```
-
-## When Not To Use It
-
-If your project's types don't yet fully describe whether certain values may be nullable, such as if you're transitioning to `strictNullChecks`, this rule might create many false reports.
-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.
-
-## Further Reading
-
-- [TypeScript 3.7 Release Notes](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html)
-- [Optional Chaining Proposal](https://github.com/tc39/proposal-optional-chaining/)

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

@@ -1,42 +0,0 @@
----
-description: 'Disallow non-null assertions using the `!` postfix operator.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/no-non-null-assertion** for documentation.
-
-TypeScript's `!` non-null assertion operator asserts to the type system that an expression is non-nullable, as in not `null` or `undefined`.
-Using assertions to tell the type system new information is often a sign that code is not fully type-safe.
-It's generally better to structure program logic so that TypeScript understands when values may be nullable.
-
-## Examples
-
-<!--tabs-->
-
-### ❌ Incorrect
-
-```ts
-interface Example {
-  property?: string;
-}
-
-declare const example: Example;
-const includesBaz = example.property!.includes('baz');
-```
-
-### ✅ Correct
-
-```ts
-interface Example {
-  property?: string;
-}
-
-declare const example: Example;
-const includesBaz = example.property?.includes('baz') ?? false;
-```
-
-## When Not To Use It
-
-If your project's types don't yet fully describe whether certain values may be nullable, such as if you're transitioning to `strictNullChecks`, this rule might create many false reports.
-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.

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-parameter-properties.md

@@ -1,12 +0,0 @@
-:::danger Deprecated
-
-This rule has been deprecated in favour of the [`parameter-properties`](https://typescript-eslint.io/rules/parameter-properties/) rule.
-
-:::
-
-<!--
-This doc file has been left on purpose 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.
--->