@nr1e/commons 0.1.0 → 0.1.1

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

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

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

@@ -0,0 +1,245 @@
+---
+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
+const promise = Promise.resolve('value');
+
+if (promise) {
+  // Do something
+}
+
+const val = promise ? 123 : 456;
+
+while (promise) {
+  // Do something
+}
+```
+
+#### ✅ Correct
+
+```ts
+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 functions that return promises where a void return is
+expected to be checked, 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
+[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
+// 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
+const getData = () => someAsyncOperation({ myArg: 'foo' });
+
+return { foo: 42, ...getData() };
+
+const getData2 = async () => {
+  await someAsyncOperation({ myArg: 'foo' });
+};
+
+return { foo: 42, ...getData2() };
+```
+
+#### ✅ Correct
+
+```ts
+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
+
+If you do not use Promises in your codebase or are not concerned with possible
+misuses of them outside of what the TypeScript compiler will check.
+
+## 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/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-mixed-enums.md

@@ -0,0 +1,88 @@
+---
+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/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-namespace.md

@@ -0,0 +1,129 @@
+---
+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
+module foo {}
+namespace foo {}
+```
+
+#### ✅ Correct
+
+```ts
+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
+module foo {}
+namespace foo {}
+declare module foo {}
+declare namespace foo {}
+```
+
+#### ✅ Correct
+
+```ts
+declare module 'foo' {}
+```
+
+### `allowDefinitionFiles`
+
+Examples of code for the `{ "allowDefinitionFiles": true }` option:
+
+<!--tabs-->
+
+#### ❌ Incorrect
+
+```ts
+// 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
+declare module 'foo' {}
+
+// anything inside a d.ts file
+```
+
+## When Not To Use It
+
+If you are using the ES2015 module syntax, then you will not need 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/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-non-null-asserted-nullish-coalescing.md

@@ -0,0 +1,49 @@
+---
+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! ?? '';
+```
+
+## 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/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-non-null-asserted-optional-chain.md

@@ -0,0 +1,35 @@
+---
+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();
+```
+
+## 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/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-non-null-assertion.md

@@ -0,0 +1,42 @@
+---
+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 does not use the `strictNullChecks` compiler option, this rule is likely useless to you.
+If your code is often wildly incorrect with respect to strict null-checking, your code may not yet be ready for this rule.