@less-unsound/eslint-plugin 0.0.1

package/docs/rules/no-function-keyword.md

@@ -0,0 +1,37 @@
+# `no-function-keyword`
+
+Disallow non-generator `function` declarations and expressions.
+
+## Rule details
+
+We have arrow functions now. They take less characters to type, don't have quirky `this` or `arguments` or `arguments.callee`.
+
+Examples of **incorrect** code for this rule:
+
+```ts
+function value(): number {
+  return 1;
+}
+```
+
+```ts
+const value = function (): number {
+  return 1;
+};
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+const value = (): number => 1;
+```
+
+```ts
+function* values(): Generator<number, void, unknown> {
+  yield 1;
+}
+```
+
+## Options
+
+This rule does not accept options.

package/docs/rules/no-generic-parameter-bounds.md

@@ -0,0 +1,25 @@
+# `no-generic-parameter-bounds`
+
+Disallow generic parameter bounds with `extends`.
+
+## Rule details
+
+Type inference is broken here and, in many cases, will force TS to infer the type of bound instead of the expected type.
+
+If subtyping actually worked in TypeScript, there would have to be `A super B` syntax too, so that you could have set an upper bound on the type too. But subtyping doesn't work in TypeScript, thus you must not use subtyping, thus you must not use `extends`.
+
+Examples of **incorrect** code for this rule:
+
+```ts
+type Box<T extends string> = T;
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+type Box<T> = T;
+```
+
+## Options
+
+This rule does not accept options.

package/docs/rules/no-getter-setter.md

@@ -0,0 +1,55 @@
+# `no-getter-setter`
+
+Disallow getters and setters in objects, classes, and interfaces.
+
+## Rule details
+
+These break the type safety, are incorrectly handled in debuggers, and lead to unexpected heisenbugs.
+
+Use explicit `getFoo` and `setFoo` functions or avoid mutable state.
+
+Examples of **incorrect** code for this rule:
+
+```ts
+const value = {
+  get foo() {
+    return 1;
+  }
+};
+```
+
+```ts
+class Value {
+  set foo(value: number) {}
+}
+```
+
+```ts
+interface Value {
+  get foo(): number;
+}
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+const value = { foo: 1 };
+```
+
+```ts
+class Value {
+  foo(): number {
+    return 1;
+  }
+}
+```
+
+```ts
+interface Value {
+  foo(): number;
+}
+```
+
+## Options
+
+This rule does not accept options.

package/docs/rules/no-global-context.md

@@ -0,0 +1,50 @@
+# `no-global-context`
+
+Disallow `this` and explicit global-object identifiers.
+
+## Rule details
+
+Don't use OOP. Don't mutate global scopes.
+
+Examples of **incorrect** code for this rule:
+
+```ts
+const value = this;
+```
+
+```ts
+interface Value {
+  value: this;
+}
+```
+
+```ts
+const value = globalThis;
+```
+
+```ts
+const value = window;
+```
+
+```ts
+const value = self;
+```
+
+```ts
+const value = global;
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+const globalThis = 1;
+const value = globalThis;
+```
+
+```ts
+const value = { globalThis: 1, window: 2, self: 3, global: 4 };
+```
+
+## Options
+
+This rule does not accept options.

package/docs/rules/no-import-code-extension.md

@@ -0,0 +1,39 @@
+# `no-import-code-extension`
+
+Disallow `.ts`, `.tsx`, and `.js` file extensions in import specifiers.
+
+## Rule details
+
+Do not introduce file extensions into imports just so that it can be run in a specific way with Node.
+
+Examples of **incorrect** code for this rule:
+
+```ts
+import { foo } from "./foo.ts";
+```
+
+```ts
+export * from "./foo.js";
+```
+
+```ts
+await import("./foo.tsx");
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+import { foo } from "./foo";
+```
+
+```ts
+export * from "./foo";
+```
+
+```ts
+await import("./foo");
+```
+
+## Options
+
+This rule does not accept options.

package/docs/rules/no-import-rename.md

@@ -0,0 +1,31 @@
+# `no-import-rename`
+
+Disallow renamed named imports.
+
+## Rule details
+
+Do not `import { Foo as Bar }` unless absolutely required. Renamed imports make it harder to debug. Prefer `import * as Foo` instead.
+
+Examples of **incorrect** code for this rule:
+
+```ts
+import { foo as bar } from "./foo";
+```
+
+```ts
+import { type Foo as Bar } from "./foo";
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+import { foo } from "./foo";
+```
+
+```ts
+import * as Foo from "./foo";
+```
+
+## Options
+
+This rule does not accept options.

package/docs/rules/no-import-type.md

@@ -0,0 +1,25 @@
+# `no-import-type`
+
+Disallow `import()` types.
+
+## Rule details
+
+Imports go into the header of the file.
+
+Examples of **incorrect** code for this rule:
+
+```ts
+type Value = import("foo").Foo;
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+import { type Foo } from "foo";
+
+type Value = Foo;
+```
+
+## Options
+
+This rule does not accept options.

package/docs/rules/no-in-operator.md

@@ -0,0 +1,23 @@
+# `no-in-operator`
+
+Disallow the `in` operator.
+
+## Rule details
+
+TypeScript has no distinction between open and closed object types. There might be no field in an object type, but there will be one at runtime. Narrowing for `in` operators is also buggy in other ways and doesn't correctly apply to either of its arguments.
+
+Examples of **incorrect** code for this rule:
+
+```ts
+const value = "name" in foo;
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+const value = foo === undefined;
+```
+
+## Options
+
+This rule does not accept options.

package/docs/rules/no-indexed-access-type.md

@@ -0,0 +1,33 @@
+# `no-indexed-access-type`
+
+Disallow indexed access types such as Foo["bar"].
+
+## Rule details
+
+They disregard variance at their use site and most likely will pin types in another library/module with both lower and upper bounds; thus, they're very detrimental to modularity. Most likely, the type of the `foo` field should be defined separately.
+
+Examples of **incorrect** code for this rule:
+
+```ts
+type Name = User["name"];
+```
+
+```ts
+type Value = Record<string, string>[string];
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+type Name = string;
+```
+
+```ts
+type User = {
+  readonly name: string;
+};
+```
+
+## Options
+
+This rule does not accept options.

package/docs/rules/no-indexed-object-type.md

@@ -0,0 +1,23 @@
+# `no-indexed-object-type`
+
+Disallow indexed object types such as `{ [key: string]: T }`, except for explicit self-recursive cases.
+
+## Rule details
+
+It's `Record<string, number>`. The only valid case is to avoid type recursion quirks in TS: `type Json = null | boolean | number | string | Json[] | { [k: string]: Json }` would emit an error with `Record<string, Json>`
+
+Examples of **incorrect** code for this rule:
+
+```ts
+type Value = { [key: string]: number };
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+type Json = boolean | string | { [key: string]: Json };
+```
+
+## Options
+
+This rule does not accept options.

package/docs/rules/no-inheritance.md

@@ -0,0 +1,31 @@
+# `no-inheritance`
+
+Disallow `extends` on classes and interfaces, except for the documented recursive-interface workaround.
+
+## Rule details
+
+There is no way to distinguish objects supporting parent and child interfaces at runtime safely.
+
+Except where it's required to untie type recursion. For example `type Foo = A<Foo>` would only work as `interface Foo extends A<Foo> {}`
+
+Overriding is allowed in JS, but Liskov substitution is not guaranteed.
+
+Examples of **incorrect** code for this rule:
+
+```ts
+class Foo extends Bar {}
+```
+
+```ts
+interface Foo extends Bar {}
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+interface Foo extends A<Foo> {}
+```
+
+## Options
+
+This rule does not accept options.

package/docs/rules/no-inline-tagged-object.md

@@ -0,0 +1,41 @@
+# `no-inline-tagged-object`
+
+Ban creating tagged objects by supplying the configured tag field directly.
+
+## Rule details
+
+Tagged objects must be created with constructors. Files with constructors must use `eslint-disable` to pass.
+
+Ban creating objects with a supplied tag, and recommend using constructors instead. For example, `{ $: "foo" }` is banned, and must use a `Foo()` constructor when `$` is the disjoint union tag.
+
+Examples of **incorrect** code for this rule:
+
+```ts
+const value = { $: "foo" };
+```
+
+```ts
+const value = { kind: "foo-bar", value: 1 };
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+const value = Foo();
+```
+
+```ts
+const value = { foo: "bar" };
+```
+
+## Options
+
+```json
+[
+  {
+    "tagName": "kind"
+  }
+]
+```
+
+Use `tagName` to change which object field is treated as the disjoint-union tag.

package/docs/rules/no-intersection-type.md

@@ -0,0 +1,23 @@
+# `no-intersection-type`
+
+Disallow intersection types.
+
+## Rule details
+
+They are so broken it's hard even to count them as intersection types. Search for amount of mentions of `intersection` and `union` in TypeScript's type checker: at the moment there are 5 and 28. In algebra, union is dual to intersection. Correct type checker would treat them equally.
+
+Examples of **incorrect** code for this rule:
+
+```ts
+type Value = A & B;
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+type Value = A | B;
+```
+
+## Options
+
+This rule does not accept options.

package/docs/rules/no-json-static-method.md

@@ -0,0 +1,46 @@
+# `no-json-static-method`
+
+Disallow `JSON.parse` and `JSON.stringify`, including access through `globalThis.JSON` and `window.JSON`.
+
+## Rule details
+
+Both functions have very broken types: `JSON.stringify(undefined) = undefined`, but the return type is `string`. Now you have `undefined` in a `string`!
+
+Always use `zod` or equivalent schema library in every case there is an `unknown`: results of `JSON.parse`, messages sent from `postMessage`, JSONs stored in localstorage, JSONs in history objects (the part of location that is not displayed in the URL), for reading configs from files (such as `package.json`), `process.env` etc.
+
+Put all calls to `JSON.*` methods in that sandbox and `eslint-ignore` them.
+
+Examples of **incorrect** code for this rule:
+
+```ts
+JSON.parse(value);
+```
+
+```ts
+JSON["stringify"](value);
+```
+
+```ts
+globalThis.JSON.parse(value);
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+const JSON = { parse: () => 1 };
+JSON.parse(value);
+```
+
+```ts
+const globalThis = { JSON: { stringify: () => "" } };
+globalThis.JSON.stringify(value);
+```
+
+```ts
+const window = { JSON: { parse: () => 1 } };
+window.JSON.parse(value);
+```
+
+## Options
+
+This rule does not accept options.

package/docs/rules/no-keyof.md

@@ -0,0 +1,35 @@
+# `no-keyof`
+
+Disallow the `keyof` type operator.
+
+## Rule details
+
+It's another type that has no theory behind it. There are no introduction or elimination forms for `keyof`, and almost all uses will end up with `as` or `any`. It was meant for typing old JavaScript libraries, not for new code.
+
+Examples of **incorrect** code for this rule:
+
+```ts
+type Keys = keyof Foo;
+```
+
+```ts
+type Mapped<T> = {
+  [K in keyof T]: K;
+};
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+type Value = string;
+```
+
+```ts
+type User = {
+  readonly name: string;
+};
+```
+
+## Options
+
+This rule does not accept options.

package/docs/rules/no-let.md

@@ -0,0 +1,31 @@
+# `no-let`
+
+Disallow `let` declarations unless mutability is required for performance.
+
+## Rule details
+
+Most likely it should be a separate function where what is now each assignment into a variable is a `return`.
+
+These break tree-shaking, make code untestable and make behavior dependent on module initialization order.
+
+Absolutely never use `let` in tests. Execution order of `test()` and `describe()` is hard to understand and will most likely lead to flaky tests.
+
+Examples of **incorrect** code for this rule:
+
+```ts
+let value = 1;
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+const value = 1;
+```
+
+## Options
+
+This rule does not accept options.
+
+## When not to use it
+
+Disable this rule when an algorithm requires mutable local state for performance.

package/docs/rules/no-mapped-object-type.md

@@ -0,0 +1,23 @@
+# `no-mapped-object-type`
+
+Disallow mapped object types.
+
+## Rule details
+
+These lack any theory behind them, don't have introduction/elimination syntax, and are buggy.
+
+Examples of **incorrect** code for this rule:
+
+```ts
+type Value<T> = { [K in keyof T]: T[K] };
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+type Value = Record<string, number>;
+```
+
+## Options
+
+This rule does not accept options.

package/docs/rules/no-never.md

@@ -0,0 +1,35 @@
+# `no-never`
+
+Disallow the `never` type keyword.
+
+## Rule details
+
+This type is only needed in cases when there are bugs in type system. Sandbox them, and `eslint-ignore` it there.
+
+Examples of **incorrect** code for this rule:
+
+```ts
+type Value = never;
+```
+
+```ts
+function fail(): never {
+  throw new Error();
+}
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+type Value = string;
+```
+
+```ts
+function value(): string {
+  return "x";
+}
+```
+
+## Options
+
+This rule does not accept options.

package/docs/rules/no-non-null-assertion.md

@@ -0,0 +1,23 @@
+# `no-non-null-assertion`
+
+Disallow non-null assertions.
+
+## Rule details
+
+It does no checks at runtime, and is essentially `x as NotNull<typeof x>`.
+
+Examples of **incorrect** code for this rule:
+
+```ts
+const value = foo!;
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+const value = foo;
+```
+
+## Options
+
+This rule does not accept options.

package/docs/rules/no-null.md

@@ -0,0 +1,31 @@
+# `no-null`
+
+Disallow both runtime `null` literals and the `null` type.
+
+## Rule details
+
+`typeof null === 'object'`, and there is `undefined` anyway. Sometimes it might be useful for working with JSON, but you should have it sandboxed in a schema layer anyway.
+
+Examples of **incorrect** code for this rule:
+
+```ts
+const value = null;
+```
+
+```ts
+type Value = string | null;
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+const value = 0;
+```
+
+```ts
+type Value = string;
+```
+
+## Options
+
+This rule does not accept options.