docs.json

[
  {
    "code": "adjacent-overload-signatures",
    "docs": "Requires overload signatures to be adjacent to each other.\n\nOverloaded signatures which are not next to each other can lead to code which is\nhard to read and maintain.\n\n### Invalid:\n\n(`bar` is declared in-between `foo` overloads)\n\n```typescript\ntype FooType = {\n  foo(s: string): void;\n  foo(n: number): void;\n  bar(): void;\n  foo(sn: string | number): void;\n};\n```\n\n```typescript\ninterface FooInterface {\n  foo(s: string): void;\n  foo(n: number): void;\n  bar(): void;\n  foo(sn: string | number): void;\n}\n```\n\n```typescript\nclass FooClass {\n  foo(s: string): void;\n  foo(n: number): void;\n  bar(): void {}\n  foo(sn: string | number): void {}\n}\n```\n\n```typescript\nexport function foo(s: string): void;\nexport function foo(n: number): void;\nexport function bar(): void {}\nexport function foo(sn: string | number): void {}\n```\n\n### Valid:\n\n(`bar` is declared after `foo`)\n\n```typescript\ntype FooType = {\n  foo(s: string): void;\n  foo(n: number): void;\n  foo(sn: string | number): void;\n  bar(): void;\n};\n```\n\n```typescript\ninterface FooInterface {\n  foo(s: string): void;\n  foo(n: number): void;\n  foo(sn: string | number): void;\n  bar(): void;\n}\n```\n\n```typescript\nclass FooClass {\n  foo(s: string): void;\n  foo(n: number): void;\n  foo(sn: string | number): void {}\n  bar(): void {}\n}\n```\n\n```typescript\nexport function foo(s: string): void;\nexport function foo(n: number): void;\nexport function foo(sn: string | number): void {}\nexport function bar(): void {}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "ban-ts-comment",
    "docs": "Disallows the use of Typescript directives without a comment.\n\nTypescript directives reduce the effectiveness of the compiler, something which\nshould only be done in exceptional circumstances. The reason why should be\ndocumented in a comment alongside the directive.\n\n### Invalid:\n\n```typescript\n// @ts-expect-error\nlet a: number = \"I am a string\";\n```\n\n```typescript\n// @ts-ignore\nlet a: number = \"I am a string\";\n```\n\n```typescript\n// @ts-nocheck\nlet a: number = \"I am a string\";\n```\n\n### Valid:\n\n```typescript\n// @ts-expect-error: Temporary workaround (see ticket #422)\nlet a: number = \"I am a string\";\n```\n\n```typescript\n// @ts-ignore: Temporary workaround (see ticket #422)\nlet a: number = \"I am a string\";\n```\n\n```typescript\n// @ts-nocheck: Temporary workaround (see ticket #422)\nlet a: number = \"I am a string\";\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "ban-types",
    "docs": "Bans the use of primitive wrapper objects (e.g. `String` the object is a wrapper\nof `string` the primitive) in addition to the non-explicit `Function` type and\nthe misunderstood `Object` type.\n\nThere are very few situations where primitive wrapper objects are desired and\nfar more often a mistake was made with the case of the primitive type. You also\ncannot assign a primitive wrapper object to a primitive leading to type issues\ndown the line. For reference, [the TypeScript handbook] also says we shouldn't\never use these wrapper objects.\n\n[the TypeScript handbook]: https://www.typescriptlang.org/docs/handbook/declaration-files/do-s-and-don-ts.html#number-string-boolean-symbol-and-object\n\nWith `Function`, it is better to explicitly define the entire function signature\nrather than use the non-specific `Function` type which won't give you type\nsafety with the function.\n\nFinally, `Object` and `{}` means \"any non-nullish value\" rather than \"any object\ntype\". `object` is a good choice for a meaning of \"any object type\".\n\n### Invalid:\n\n```typescript\nlet a: Boolean;\nlet b: String;\nlet c: Number;\nlet d: Symbol;\nlet e: Function;\nlet f: Object;\nlet g: {};\n```\n\n### Valid:\n\n```typescript\nlet a: boolean;\nlet b: string;\nlet c: number;\nlet d: symbol;\nlet e: () => number;\nlet f: object;\nlet g: Record<string, never>;\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "ban-unknown-rule-code",
    "docs": "Warns the usage of unknown rule codes in ignore directives\n\nWe sometimes have to suppress and ignore lint errors for some reasons. We can do\nso using [ignore directives](https://lint.deno.land/ignoring-rules) with rule\nnames that should be ignored like so:\n\n```typescript\n// deno-lint-ignore no-explicit-any no-unused-vars\nconst foo: any = 42;\n```\n\nThis rule checks for the validity of the specified rule names (i.e. whether\n`deno_lint` provides the rule or not).\n\n### Invalid:\n\n```typescript\n// typo\n// deno-lint-ignore eq-eq-e\nconsole.assert(x == 42);\n\n// unknown rule name\n// deno-lint-ignore UNKNOWN_RULE_NAME\nconst b = \"b\";\n```\n\n### Valid:\n\n```typescript\n// deno-lint-ignore eq-eq-eq\nconsole.assert(x == 42);\n\n// deno-lint-ignore no-unused-vars\nconst b = \"b\";\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "ban-untagged-ignore",
    "docs": "Requires `deno-lint-ignore` to be annotated with one or more rule names.\n\nIgnoring all rules can mask unexpected or future problems. Therefore you need to\nexplicitly specify which rule(s) are to be ignored.\n\n### Invalid:\n\n```typescript\n// deno-lint-ignore\nexport function duplicateArgumentsFn(a, b, a) {}\n```\n\n### Valid:\n\n```typescript\n// deno-lint-ignore no-dupe-args\nexport function duplicateArgumentsFn(a, b, a) {}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "ban-untagged-todo",
    "docs": "Requires TODOs to be annotated with either a user tag (`@user`) or an issue\nreference (`#issue`).\n\nTODOs without reference to a user or an issue become stale with no easy way to\nget more information.\n\n### Invalid:\n\n```typescript\n// TODO Improve calc engine\nexport function calcValue(): number {}\n```\n\n```typescript\n// TODO Improve calc engine (@djones)\nexport function calcValue(): number {}\n```\n\n```typescript\n// TODO Improve calc engine (#332)\nexport function calcValue(): number {}\n```\n\n### Valid:\n\n```typescript\n// TODO(djones) Improve calc engine\nexport function calcValue(): number {}\n```\n\n```typescript\n// TODO(@djones) Improve calc engine\nexport function calcValue(): number {}\n```\n\n```typescript\n// TODO(#332)\nexport function calcValue(): number {}\n```\n\n```typescript\n// TODO(#332) Improve calc engine\nexport function calcValue(): number {}\n```\n",
    "tags": []
  },
  {
    "code": "ban-unused-ignore",
    "docs": "Warns unused ignore directives\n\nWe sometimes have to suppress and ignore lint errors for some reasons and we can\ndo so using [ignore directives](https://lint.deno.land/ignoring-rules).\n\nIn some cases, however, like after refactoring, we may end up having ignore\ndirectives that are no longer necessary. Such superfluous ignore directives are\nlikely to confuse future code readers, and to make matters worse, might hide\nfuture lint errors unintentionally. To prevent such situations, this rule\ndetects unused, superfluous ignore directives.\n\n### Invalid:\n\n```typescript\n// Actually this line is valid since `export` means \"used\",\n// so this directive is superfluous\n// deno-lint-ignore no-unused-vars\nexport const foo = 42;\n```\n\n### Valid:\n\n```typescript\nexport const foo = 42;\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "camelcase",
    "docs": "Enforces the use of camelCase in variable names\n\nConsistency in a code base is key for readability and maintainability. This rule\nenforces variable declarations and object property names which you create to be\nin camelCase.\n\nOf note:\n\n- `_` is allowed at the start or end of a variable\n- All uppercase variable names (e.g. constants) may have `_` in their name\n- If you have to use a snake_case key in an object for some reasons, wrap it in\n  quotation mark\n- This rule also applies to variables imported or exported via ES modules, but\n  not to object properties of those variables\n\n### Invalid:\n\n```typescript\nlet first_name = \"Ichigo\";\nconst obj1 = { last_name: \"Hoshimiya\" };\nconst obj2 = { first_name };\nconst { last_name } = obj1;\n\nfunction do_something() {}\nfunction foo({ snake_case = \"default value\" }) {}\n\nclass snake_case_class {}\nclass Also_Not_Valid_Class {}\n\nimport { not_camelCased } from \"external-module.js\";\nexport * as not_camelCased from \"mod.ts\";\n\nenum snake_case_enum {\n  snake_case_variant,\n}\n\ntype snake_case_type = { some_property: number };\n\ninterface snake_case_interface {\n  some_property: number;\n}\n```\n\n### Valid:\n\n```typescript\nlet firstName = \"Ichigo\";\nconst FIRST_NAME = \"Ichigo\";\nconst __myPrivateVariable = \"Hoshimiya\";\nconst myPrivateVariable_ = \"Hoshimiya\";\nconst obj1 = { \"last_name\": \"Hoshimiya\" }; // if an object key is wrapped in quotation mark, then it's valid\nconst obj2 = { \"first_name\": first_name };\nconst { last_name: lastName } = obj;\n\nfunction doSomething() {} // function declarations must be camelCase but...\ndo_something(); // ...snake_case function calls are allowed\nfunction foo({ snake_case: camelCase = \"default value\" }) {}\n\nclass PascalCaseClass {}\n\nimport { not_camelCased as camelCased } from \"external-module.js\";\nexport * as camelCased from \"mod.ts\";\n\nenum PascalCaseEnum {\n  PascalCaseVariant,\n}\n\ntype PascalCaseType = { someProperty: number };\n\ninterface PascalCaseInterface {\n  someProperty: number;\n}\n```\n",
    "tags": []
  },
  {
    "code": "constructor-super",
    "docs": "Verifies the correct usage of constructors and calls to `super()`.\n\nDefined constructors of derived classes (e.g. `class A extends B`) must always\ncall `super()`. Classes which extend non-constructors (e.g.\n`class A extends null`) must not have a constructor.\n\n### Invalid:\n\n```typescript\nclass A {}\nclass Z {\n  constructor() {}\n}\n\nclass B extends Z {\n  constructor() {} // missing super() call\n}\nclass C {\n  constructor() {\n    super(); // Syntax error\n  }\n}\nclass D extends null {\n  constructor() {} // illegal constructor\n}\nclass E extends null {\n  constructor() { // illegal constructor\n    super();\n  }\n}\n```\n\n### Valid:\n\n```typescript\nclass A {}\nclass B extends A {}\nclass C extends A {\n  constructor() {\n    super();\n  }\n}\nclass D extends null {}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "default-param-last",
    "docs": "Enforces default parameter(s) to be last in the function signature.\n\nParameters with default values are optional by nature but cannot be left out of\nthe function call without mapping the function inputs to different parameters\nwhich is confusing and error prone. Specifying them last allows them to be left\nout without changing the semantics of the other parameters.\n\n### Invalid:\n\n```typescript\nfunction f(a = 2, b) {}\nfunction f(a = 5, b, c = 5) {}\n```\n\n### Valid:\n\n```typescript\nfunction f() {}\nfunction f(a) {}\nfunction f(a = 5) {}\nfunction f(a, b = 5) {}\nfunction f(a, b = 5, c = 5) {}\nfunction f(a, b = 5, ...c) {}\nfunction f(a = 2, b = 3) {}\n```\n",
    "tags": []
  },
  {
    "code": "eqeqeq",
    "docs": "Enforces the use of type-safe equality operators `===` and `!==` instead of the\nmore error prone `==` and `!=` operators.\n\n`===` and `!==` ensure the comparators are of the same type as well as the same\nvalue. On the other hand `==` and `!=` do type coercion before value checking\nwhich can lead to unexpected results. For example `5 == \"5\"` is `true`, while\n`5 === \"5\"` is `false`.\n\n### Invalid:\n\n```typescript\nif (a == 5) {}\nif (\"hello world\" != input) {}\n```\n\n### Valid:\n\n```typescript\nif (a === 5) {}\nif (\"hello world\" !== input) {}\n```\n",
    "tags": []
  },
  {
    "code": "explicit-function-return-type",
    "docs": "Requires all functions to have explicit return types.\n\nExplicit return types have a number of advantages including easier to understand\ncode and better type safety. It is clear from the signature what the return type\nof the function (if any) will be.\n\n### Invalid:\n\n```typescript\nfunction someCalc() {\n  return 2 * 2;\n}\nfunction anotherCalc() {\n  return;\n}\n```\n\n### Valid:\n\n```typescript\nfunction someCalc(): number {\n  return 2 * 2;\n}\nfunction anotherCalc(): void {\n  return;\n}\n```\n",
    "tags": []
  },
  {
    "code": "explicit-module-boundary-types",
    "docs": "Requires all module exports to have fully typed declarations\n\nHaving fully typed function arguments and return values clearly defines the\ninputs and outputs of a module (known as the module boundary). This will make it\nvery clear to any users of the module how to supply inputs and handle outputs in\na type safe manner.\n\n### Invalid:\n\n```typescript\n// Missing return type (e.g. void)\nexport function printDoc(doc: string, doubleSided: boolean) {\n  return;\n}\n\n// Missing argument type (e.g. `arg` is of type string)\nexport const arrowFn = (arg): string => `hello ${arg}`;\n\n// Missing return type (e.g. boolean)\nexport function isValid() {\n  return true;\n}\n```\n\n### Valid:\n\n```typescript\n// Typed input parameters and return value\nexport function printDoc(doc: string, doubleSided: boolean): void {\n  return;\n}\n\n// Input of type string and a return value of type string\nexport const arrowFn = (arg: string): string => `hello ${arg}`;\n\n// Though lacking a return type, this is valid as it is not exported\nfunction isValid() {\n  return true;\n}\n```\n",
    "tags": []
  },
  {
    "code": "for-direction",
    "docs": "Requires `for` loop control variables to increment in the correct direction\n\nIncrementing `for` loop control variables in the wrong direction leads to\ninfinite loops. This can occur through incorrect initialization, bad\ncontinuation step logic or wrong direction incrementing of the loop control\nvariable.\n\n### Invalid:\n\n```typescript\n// Infinite loop\nfor (let i = 0; i < 2; i--) {}\n```\n\n### Valid:\n\n```typescript\nfor (let i = 0; i < 2; i++) {}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "fresh-handler-export",
    "docs": "Checks correct naming for named fresh middleware export\n\nFiles inside the `routes/` folder can export middlewares that run before any\nrendering happens. They are expected to be available as a named export called\n`handler`. This rule checks for when the export was incorrectly named `handlers`\ninstead of `handler`.\n\n### Invalid:\n\n```js\nexport const handlers = {\n  GET() {},\n  POST() {},\n};\nexport function handlers() {}\nexport async function handlers() {}\n```\n\n### Valid:\n\n```jsx\nexport const handler = {\n  GET() {},\n  POST() {},\n};\nexport function handler() {}\nexport async function handler() {}\n```\n",
    "tags": [
      "fresh"
    ]
  },
  {
    "code": "fresh-server-event-handlers",
    "docs": "Disallows event handlers in fresh server components\n\nComponents inside the `routes/` folder in a fresh app are exclusively rendered\non the server. They are not rendered in the client and setting an event handler\nwill have no effect.\n\nNote that this rule only applies to server components inside the `routes/`\nfolder, not to fresh islands or any other components.\n\n### Invalid:\n\n```jsx\n<button onClick={() => {}} />\n<button onclick={() => {}} />\n<my-custom-element foo={() => {}} />\n```\n\n### Valid:\n\n```jsx\n<button />\n<my-custom-element />\n```\n",
    "tags": [
      "fresh"
    ]
  },
  {
    "code": "getter-return",
    "docs": "Requires all property getter functions to return a value\n\nGetter functions return the value of a property. If the function returns no\nvalue then this contract is broken.\n\n### Invalid:\n\n```typescript\nlet foo = {\n  get bar() {},\n};\n\nclass Person {\n  get name() {}\n}\n```\n\n### Valid:\n\n```typescript\nlet foo = {\n  get bar() {\n    return true;\n  },\n};\n\nclass Person {\n  get name() {\n    return \"alice\";\n  }\n}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "guard-for-in",
    "docs": "Require `for-in` loops to include an `if` statement\n\nLooping over objects with a `for-in` loop will include properties that are\ninherited through the prototype chain. This behavior can lead to unexpected\nitems in your for loop.\n\n### Invalid:\n\n```typescript\nfor (const key in obj) {\n  foo(obj, key);\n}\n```\n\n### Valid:\n\n```typescript\nfor (const key in obj) {\n  if (Object.hasOwn(obj, key)) {\n    foo(obj, key);\n  }\n}\n```\n\n```typescript\nfor (const key in obj) {\n  if (!Object.hasOwn(obj, key)) {\n    continue;\n  }\n  foo(obj, key);\n}\n```\n",
    "tags": []
  },
  {
    "code": "no-array-constructor",
    "docs": "Enforce conventional usage of array construction\n\nArray construction is conventionally done via literal notation such as `[]` or\n`[1, 2, 3]`. Using the `new Array()` is discouraged as is `new Array(1, 2, 3)`.\nThere are two reasons for this. The first is that a single supplied argument\ndefines the array length, while multiple arguments instead populate the array of\nno fixed size. This confusion is avoided when pre-populated arrays are only\ncreated using literal notation. The second argument to avoiding the `Array`\nconstructor is that the `Array` global may be redefined.\n\nThe one exception to this rule is when creating a new array of fixed size, e.g.\n`new Array(6)`. This is the conventional way to create arrays of fixed length.\n\n### Invalid:\n\n```typescript\n// This is 4 elements, not a size 100 array of 3 elements\nconst a = new Array(100, 1, 2, 3);\n\nconst b = new Array(); // use [] instead\n```\n\n### Valid:\n\n```typescript\nconst a = new Array(100);\nconst b = [];\nconst c = [1, 2, 3];\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-async-promise-executor",
    "docs": "Requires that async promise executor functions are not used\n\nPromise constructors take an executor function as an argument with `resolve` and\n`reject` parameters that can be used to control the state of the created\nPromise. This function is allowed to be async but this is generally not a good\nidea for several reasons:\n\n- If an async executor function throws an error, the error will be lost and\n  won't cause the newly-constructed Promise to reject. This could make it\n  difficult to debug and handle some errors.\n- If an async Promise executor function is using await, then this is usually a\n  sign that it is not actually necessary to use the new Promise constructor and\n  the code can be restructured to avoid the use of a promise, or the scope of\n  the new Promise constructor can be reduced, extracting the async code and\n  changing it to be synchronous.\n\n### Invalid:\n\n```typescript\nnew Promise(async function (resolve, reject) {});\nnew Promise(async (resolve, reject) => {});\n```\n\n### Valid:\n\n```typescript\nnew Promise(function (resolve, reject) {});\nnew Promise((resolve, reject) => {});\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-await-in-loop",
    "docs": "Requires `await` is not used in a for loop body\n\nAsync and await are used in Javascript to provide parallel execution. If each\nelement in the for loop is waited upon using `await`, then this negates the\nbenefits of using async/await as no more elements in the loop can be processed\nuntil the current element finishes.\n\nA common solution is to refactor the code to run the loop body asynchronously\nand capture the promises generated. After the loop finishes you can then await\nall the promises at once.\n\n### Invalid:\n\n```javascript\nasync function doSomething(items) {\n  const results = [];\n  for (const item of items) {\n    // Each item in the array blocks on the previous one finishing\n    results.push(await someAsyncProcessing(item));\n  }\n  return processResults(results);\n}\n```\n\n### Valid:\n\n```javascript\nasync function doSomething(items) {\n  const results = [];\n  for (const item of items) {\n    // Kick off all item processing asynchronously...\n    results.push(someAsyncProcessing(item));\n  }\n  // ...and then await their completion after the loop\n  return processResults(await Promise.all(results));\n}\n```\n",
    "tags": []
  },
  {
    "code": "no-await-in-sync-fn",
    "docs": "Disallow `await` keyword inside a non-async function\n\nUsing the `await` keyword inside a non-async function is a syntax error. To be\nable to use `await` inside a function, the function needs to be marked as async\nvia the `async` keyword\n\n### Invalid:\n\n```javascript\nfunction foo() {\n  await bar();\n}\n\nconst fooFn = function foo() {\n  await bar();\n};\n\nconst fooFn = () => {\n  await bar();\n};\n```\n\n### Valid:\n\n```javascript\nasync function foo() {\n  await bar();\n}\n\nconst fooFn = async function foo() {\n  await bar();\n};\n\nconst fooFn = async () => {\n  await bar();\n};\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-boolean-literal-for-arguments",
    "docs": "Requires all functions called with any amount of `boolean` literals as\nparameters to use a self-documenting constant instead.\n\nIs common to define functions that can take `booleans` as arguments. However,\npassing `boolean` literals as parameters can lead to lack of context regarding\nthe role of the argument inside the function in question.\n\nA simple fix for the points mentioned above is the use of self documenting\nconstants that will end up working as \"named booleans\", that allow for a better\nunderstanding on what the parameters mean in the context of the function call.\n\n### Invalid\n\n```typescript\nfunction redraw(allViews: boolean, inline: boolean) {\n  // redraw logic.\n}\nredraw(true, true);\n\nfunction executeCommand(recursive: boolean, executionMode: EXECUTION_MODES) {\n  // executeCommand logic.\n}\nexecuteCommand(true, EXECUTION_MODES.ONE);\n\nfunction enableLogs(enable: boolean) {\n  // enabledLogs logic.\n}\nenableLogs(true);\n```\n\n### Valid\n\n```typescript\nfunction redraw(allViews: boolean, inline: boolean) {\n  // redraw logic.\n}\nconst ALL_VIEWS = true, INLINE = true;\nredraw(ALL_VIEWS, INLINE);\n\nfunction executeCommand(recursive: boolean, executionMode: EXECUTION_MODES) {\n  // executeCommand logic.\n}\nconst RECURSIVE = true;\nexecuteCommand(RECURSIVE, EXECUTION_MODES.ONE);\n\nfunction enableLogs(enable: boolean) {\n  // enabledLogs logic.\n}\nconst ENABLE = true;\nenableLogs(ENABLE);\n```\n",
    "tags": []
  },
  {
    "code": "no-case-declarations",
    "docs": "Requires lexical declarations (`let`, `const`, `function` and `class`) in switch\n`case` or `default` clauses to be scoped with brackets.\n\nWithout brackets in the `case` or `default` block, the lexical declarations are\nvisible to the entire switch block but only get initialized when they are\nassigned, which only happens if that case/default is reached. This can lead to\nunexpected errors. The solution is to ensure each `case` or `default` block is\nwrapped in brackets to scope limit the declarations.\n\n### Invalid:\n\n```typescript\nswitch (choice) {\n  // `let`, `const`, `function` and `class` are scoped the entire switch statement here\n  case 1:\n    let a = \"choice 1\";\n    break;\n  case 2:\n    const b = \"choice 2\";\n    break;\n  case 3:\n    function f() {\n      return \"choice 3\";\n    }\n    break;\n  default:\n    class C {}\n}\n```\n\n### Valid:\n\n```typescript\nswitch (choice) {\n  // The following `case` and `default` clauses are wrapped into blocks using brackets\n  case 1: {\n    let a = \"choice 1\";\n    break;\n  }\n  case 2: {\n    const b = \"choice 2\";\n    break;\n  }\n  case 3: {\n    function f() {\n      return \"choice 3\";\n    }\n    break;\n  }\n  default: {\n    class C {}\n  }\n}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-class-assign",
    "docs": "Disallows modifying variables of class declarations\n\nDeclaring a class such as `class A {}`, creates a variable `A`. Like any\nvariable this can be modified or reassigned. In most cases this is a mistake and\nnot what was intended.\n\n### Invalid:\n\n```typescript\nclass A {}\nA = 0; // reassigning the class variable itself\n```\n\n### Valid:\n\n```typescript\nclass A {}\nlet c = new A();\nc = 0; // reassigning the variable `c`\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-compare-neg-zero",
    "docs": "Disallows comparing against negative zero (`-0`).\n\nComparing a value directly against negative may not work as expected as it will\nalso pass for non-negative zero (i.e. `0` and `+0`). Explicit comparison with\nnegative zero can be performed using `Object.is`.\n\n### Invalid:\n\n```typescript\nif (x === -0) {}\n```\n\n### Valid:\n\n```typescript\nif (x === 0) {}\n\nif (Object.is(x, -0)) {}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-cond-assign",
    "docs": "Disallows the use of the assignment operator, `=`, in conditional statements.\n\nUse of the assignment operator within a conditional statement is often the\nresult of mistyping the equality operator, `==`. If an assignment within a\nconditional statement is required then this rule allows it by wrapping the\nassignment in parentheses.\n\n### Invalid:\n\n```typescript\nlet x;\nif (x = 0) {\n  let b = 1;\n}\n```\n\n```typescript\nfunction setHeight(someNode) {\n  do {\n    someNode.height = \"100px\";\n  } while (someNode = someNode.parentNode);\n}\n```\n\n### Valid:\n\n```typescript\nlet x;\nif (x === 0) {\n  let b = 1;\n}\n```\n\n```typescript\nfunction setHeight(someNode) {\n  do {\n    someNode.height = \"100px\";\n  } while ((someNode = someNode.parentNode));\n}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-console",
    "docs": "Disallows the use of the `console` global.\n\nOftentimes, developers accidentally commit `console.log`/`console.error`\nstatements, left in particularly after debugging. Moreover, using these in code\nmay leak sensitive information to the output or clutter the console with\nunnecessary information. This rule helps maintain clean and secure code by\ndisallowing the use of `console`.\n\nThis rule is especially useful in libraries where you almost never want to\noutput to the console.\n\n### Invalid\n\n```typescript\nconsole.log(\"Debug message\");\nconsole.error(\"Debug message\");\nconsole.debug(obj);\n\nif (debug) console.log(\"Debugging\");\n\nfunction log() {\n  console.log(\"Log\");\n}\n```\n\n### Valid\n\nIt is recommended to explicitly enable the console via a `deno-lint-ignore`\ncomment for any calls where you actually want to use it.\n\n```typescript\nfunction logWarning(message: string) {\n  // deno-lint-ignore no-console\n  console.warn(message);\n}\n```\n",
    "tags": []
  },
  {
    "code": "no-const-assign",
    "docs": "Disallows modifying a variable declared as `const`.\n\nModifying a variable declared as `const` will result in a runtime error.\n\n### Invalid:\n\n```typescript\nconst a = 0;\na = 1;\na += 1;\na++;\n++a;\n```\n\n### Valid:\n\n```typescript\nconst a = 0;\nconst b = a + 1;\n\n// `c` is out of scope on each loop iteration, allowing a new assignment\nfor (const c in [1, 2, 3]) {}\n```\n",
    "tags": []
  },
  {
    "code": "no-constant-condition",
    "docs": "Disallows the use of a constant expression in conditional test\n\nUsing a constant expression in a conditional test is often either a mistake or a\ntemporary situation introduced during development and is not ready for\nproduction.\n\n### Invalid:\n\n```typescript\nif (true) {}\nif (2) {}\ndo {} while (x = 2); // infinite loop\n```\n\n### Valid:\n\n```typescript\nif (x) {}\nif (x === 0) {}\ndo {} while (x === 2);\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-control-regex",
    "docs": "Disallows the use ascii control characters in regular expressions\n\nControl characters are invisible characters in the ASCII range of 0-31. It is\nuncommon to use these in a regular expression and more often it is a mistake in\nthe regular expression.\n\n### Invalid:\n\n```typescript\n// Examples using ASCII (31) Carriage Return (hex x0d)\nconst pattern1 = /\\x0d/;\nconst pattern2 = /\\u000d/;\nconst pattern3 = new RegExp(\"\\\\x0d\");\nconst pattern4 = new RegExp(\"\\\\u000d\");\n```\n\n### Valid:\n\n```typescript\n// Examples using ASCII (32) Space (hex x20)\nconst pattern1 = /\\x20/;\nconst pattern2 = /\\u0020/;\nconst pattern3 = new RegExp(\"\\\\x20\");\nconst pattern4 = new RegExp(\"\\\\u0020\");\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-debugger",
    "docs": "Disallows the use of the `debugger` statement\n\n`debugger` is a statement which is meant for stopping the javascript execution\nenvironment and start the debugger at the statement. Modern debuggers and\ntooling no longer need this statement and leaving it in can cause the execution\nof your code to stop in production.\n\n### Invalid:\n\n```typescript\nfunction isLongString(x: string) {\n  debugger;\n  return x.length > 100;\n}\n```\n\n### Valid:\n\n```typescript\nfunction isLongString(x: string) {\n  return x.length > 100; // set breakpoint here instead\n}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-delete-var",
    "docs": "Disallows the deletion of variables\n\n`delete` is used to remove a property from an object. Variables declared via\n`var`, `let` and `const` cannot be deleted (`delete` will return `false`).\nSetting `strict` mode on will raise a syntax error when attempting to delete a\nvariable.\n\n### Invalid:\n\n```typescript\nconst a = 1;\nlet b = 2;\nlet c = 3;\ndelete a; // would return false\ndelete b; // would return false\ndelete c; // would return false\n```\n\n### Valid:\n\n```typescript\nlet obj = {\n  a: 1,\n};\ndelete obj.a; // return true\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-deprecated-deno-api",
    "docs": "Warns the usage of the deprecated - Deno APIs\n\nThe following APIs will be removed from the `Deno.*` namespace but have newer\nAPIs to migrate to. See the\n[Deno 1.x to 2.x Migration Guide](https://docs.deno.com/runtime/manual/advanced/migrate_deprecations)\nfor migration instructions.\n\n- `Deno.Buffer`\n- `Deno.Closer`\n- `Deno.close()`\n- `Deno.Conn.rid`\n- `Deno.copy()`\n- `Deno.customInspect`\n- `Deno.File`\n- `Deno.fstatSync()`\n- `Deno.fstat()`\n- `Deno.FsWatcher.rid`\n- `Deno.ftruncateSync()`\n- `Deno.ftruncate()`\n- `Deno.futimeSync()`\n- `Deno.futime()`\n- `Deno.isatty()`\n- `Deno.Listener.rid`\n- `Deno.ListenTlsOptions.certFile`\n- `Deno.ListenTlsOptions.keyFile`\n- `Deno.readAllSync()`\n- `Deno.readAll()`\n- `Deno.Reader`\n- `Deno.ReaderSync`\n- `Deno.readSync()`\n- `Deno.read()`\n- `Deno.run()`\n- `Deno.seekSync()`\n- `Deno.seek()`\n- `Deno.serveHttp()`\n- `Deno.Server`\n- `Deno.shutdown`\n- `Deno.stderr.rid`\n- `Deno.stdin.rid`\n- `Deno.stdout.rid`\n- `Deno.TlsConn.rid`\n- `Deno.UnixConn.rid`\n- `Deno.writeAllSync()`\n- `Deno.writeAll()`\n- `Deno.Writer`\n- `Deno.WriterSync`\n- `Deno.writeSync()`\n- `Deno.write()`\n- `new Deno.FsFile()`\n\nThe following APIs will be removed from the `Deno.*` namespace without\nreplacement.\n\n- `Deno.resources()`\n- `Deno.metrics()`\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-dupe-args",
    "docs": "Disallows using an argument name more than once in a function signature\n\nIf you supply multiple arguments of the same name to a function, the last\ninstance will shadow the preceding one(s). This is most likely an unintentional\ntypo.\n\n### Invalid:\n\n```typescript\nfunction withDupes(a, b, a) {\n  console.log(\"I'm the value of the second a:\", a);\n}\n```\n\n### Valid:\n\n```typescript\nfunction withoutDupes(a, b, c) {\n  console.log(\"I'm the value of the first (and only) a:\", a);\n}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-dupe-class-members",
    "docs": "Disallows using a class member function name more than once\n\nDeclaring a function of the same name twice in a class will cause the previous\ndeclaration(s) to be overwritten, causing unexpected behaviors.\n\n### Invalid:\n\n```typescript\nclass Foo {\n  bar() {}\n  bar() {}\n}\n```\n\n### Valid:\n\n```typescript\nclass Foo {\n  bar() {}\n  fizz() {}\n}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-dupe-else-if",
    "docs": "Disallows using the same condition twice in an `if`/`else if` statement\n\nWhen you reuse a condition in an `if`/`else if` statement, the duplicate\ncondition will never be reached (without unusual side-effects) meaning this is\nalmost always a bug.\n\n### Invalid:\n\n```typescript\nif (a) {}\nelse if (b) {}\nelse if (a) {} // duplicate of condition above\n\nif (a === 5) {}\nelse if (a === 6) {}\nelse if (a === 5) {} // duplicate of condition above\n```\n\n### Valid:\n\n```typescript\nif (a) {}\nelse if (b) {}\nelse if (c) {}\n\nif (a === 5) {}\nelse if (a === 6) {}\nelse if (a === 7) {}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-dupe-keys",
    "docs": "Disallows duplicate keys in object literals.\n\nSetting the same key multiple times in an object literal will override other\nassignments to that key and can cause unexpected behaviour.\n\n### Invalid:\n\n```typescript\nconst foo = {\n  bar: \"baz\",\n  bar: \"qux\",\n};\n```\n\n```typescript\nconst foo = {\n  \"bar\": \"baz\",\n  bar: \"qux\",\n};\n```\n\n```typescript\nconst foo = {\n  0x1: \"baz\",\n  1: \"qux\",\n};\n```\n\n### Valid:\n\n```typescript\nconst foo = {\n  bar: \"baz\",\n  quxx: \"qux\",\n};\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-duplicate-case",
    "docs": "Disallows using the same case clause in a switch statement more than once\n\nWhen you reuse a case test expression in a `switch` statement, the duplicate\ncase will never be reached meaning this is almost always a bug.\n\n### Invalid:\n\n```typescript\nconst someText = \"a\";\nswitch (someText) {\n  case \"a\": // (1)\n    break;\n  case \"b\":\n    break;\n  case \"a\": // duplicate of (1)\n    break;\n  default:\n    break;\n}\n```\n\n### Valid:\n\n```typescript\nconst someText = \"a\";\nswitch (someText) {\n  case \"a\":\n    break;\n  case \"b\":\n    break;\n  case \"c\":\n    break;\n  default:\n    break;\n}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-empty",
    "docs": "Disallows the use of empty block statements.\n\nEmpty block statements are legal but often represent that something was missed\nand can make code less readable. This rule ignores block statements that only\ncontain comments. This rule also ignores empty constructors and function bodies\n(including arrow functions).\n\n### Invalid:\n\n```typescript\nif (foo) {}\n\nwhile (foo) {}\n\nswitch (foo) {}\n\ntry {\n  doSomething();\n} catch (e) {\n} finally {\n}\n```\n\n### Valid:\n\n```typescript\nif (foo) {\n  // empty\n}\n\nwhile (foo) {\n  /* empty */\n}\n\ntry {\n  doSomething();\n} catch (e) {\n  // continue regardless of error\n}\n\ntry {\n  doSomething();\n} finally {\n  /* continue regardless of error */\n}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-empty-character-class",
    "docs": "Disallows using the empty character class in a regular expression\n\nRegular expression character classes are a series of characters in brackets,\ne.g. `[abc]`. if nothing is supplied in the brackets it will not match anything\nwhich is likely a typo or mistake.\n\n### Invalid:\n\n```typescript\n/^abc[]/.test(\"abcdefg\"); // false, as `d` does not match an empty character class\n\"abcdefg\".match(/^abc[]/); // null\n```\n\n### Valid:\n\n```typescript\n// Without a character class\n/^abc/.test(\"abcdefg\"); // true\n\"abcdefg\".match(/^abc/); // [\"abc\"]\n\n// With a valid character class\n/^abc[a-z]/.test(\"abcdefg\"); // true\n\"abcdefg\".match(/^abc[a-z]/); // [\"abcd\"]\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-empty-enum",
    "docs": "Disallows the declaration of an empty enum\n\nAn enum with no members serves no purpose. This rule will capture these\nsituations as either unnecessary code or a mistaken empty implementation.\n\n### Invalid:\n\n```typescript\nenum Foo {}\n```\n\n### Valid:\n\n```typescript\nenum Foo {\n  ONE = \"ONE\",\n}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-empty-interface",
    "docs": "Disallows the declaration of an empty interface\n\nAn interface with no members serves no purpose. This rule will capture these\nsituations as either unnecessary code or a mistaken empty implementation.\n\n### Invalid:\n\n```typescript\ninterface Foo {}\n```\n\n### Valid:\n\n```typescript\ninterface Foo {\n  name: string;\n}\n\ninterface Bar {\n  age: number;\n}\n\n// Using an empty interface with at least one extension are allowed.\n\n// Using an empty interface to change the identity of Baz from type to interface.\ntype Baz = { profession: string };\ninterface Foo extends Baz {}\n\n// Using an empty interface to extend already existing Foo declaration\n// with members of the Bar interface\ninterface Foo extends Bar {}\n\n// Using an empty interface as a union type\ninterface Baz extends Foo, Bar {}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-empty-pattern",
    "docs": "Disallows the use of empty patterns in destructuring\n\nIn destructuring, it is possible to use empty patterns such as `{}` or `[]`\nwhich have no effect, most likely not what the author intended.\n\n### Invalid:\n\n```typescript\n// In these examples below, {} and [] are not object literals or empty arrays,\n// but placeholders for destructured variable names\nconst {} = someObj;\nconst [] = someArray;\nconst {a: {}} = someObj;\nconst [a: []] = someArray;\nfunction myFunc({}) {}\nfunction myFunc([]) {}\n```\n\n### Valid:\n\n```typescript\nconst { a } = someObj;\nconst [a] = someArray;\n\n// Correct way to default destructured variable to object literal\nconst { a = {} } = someObj;\n\n// Correct way to default destructured variable to empty array\nconst [a = []] = someArray;\n\nfunction myFunc({ a }) {}\nfunction myFunc({ a = {} }) {}\nfunction myFunc([a]) {}\nfunction myFunc([a = []]) {}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-eval",
    "docs": "Disallows the use of `eval`\n\n`eval` is a potentially dangerous function which can open your code to a number\nof security vulnerabilities. In addition to being slow, `eval` is also often\nunnecessary with better solutions available.\n\n### Invalid:\n\n```typescript\nconst obj = { x: \"foo\" };\nconst key = \"x\",\nconst value = eval(\"obj.\" + key);\n```\n\n### Valid:\n\n```typescript\nconst obj = { x: \"foo\" };\nconst value = obj[x];\n```\n",
    "tags": []
  },
  {
    "code": "no-ex-assign",
    "docs": "Disallows the reassignment of exception parameters\n\nThere is generally no good reason to reassign an exception parameter. Once\nreassigned the code from that point on has no reference to the error anymore.\n\n### Invalid:\n\n```typescript\ntry {\n  someFunc();\n} catch (e) {\n  e = true;\n  // can no longer access the thrown error\n}\n```\n\n### Valid:\n\n```typescript\ntry {\n  someFunc();\n} catch (e) {\n  const anotherVar = true;\n}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-explicit-any",
    "docs": "Disallows use of the `any` type\n\nUse of the `any` type disables the type check system around that variable,\ndefeating the purpose of Typescript which is to provide type safe code.\nAdditionally, the use of `any` hinders code readability, since it is not\nimmediately clear what type of value is being referenced. It is better to be\nexplicit about all types. For a more type-safe alternative to `any`, use\n`unknown` if you are unable to choose a more specific type.\n\n### Invalid:\n\n```typescript\nconst someNumber: any = \"two\";\nfunction foo(): any {\n  return undefined;\n}\n```\n\n### Valid:\n\n```typescript\nconst someNumber: string = \"two\";\nfunction foo(): undefined {\n  return undefined;\n}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-external-import",
    "docs": "Disallows the use of external imports\n\n- what's the motivation of this lint rule?\n  - this rule emits warnings if external modules are imported via URL. \"deps.ts\"\n    and import maps are exception.\n- why is linted code considered bad?\n  - importing external modules just works fine, but it will take time and effort\n    when you want to upgrade those modules if they are imported in multiple\n    places in your project.\n- who should use it?\n  - to avoid it you could use \"deps.ts convention\" or\n    [import maps](https://docs.deno.com/runtime/manual/basics/import_maps),\n    where you import all external modules and then re-export them or assign\n    aliases to them.\n  - so if you'd like to follow the \"deps.ts convention\" or to use import maps,\n    this rule is for you.\n\n### Invalid:\n\n```typescript\nimport { assertEquals } from \"https://deno.land/std@0.126.0/testing/asserts.ts\";\n```\n\n### Valid:\n\n```typescript\nimport { assertEquals } from \"./deps.ts\";\n```\n\n```typescript\n// deps.ts\n\nexport {\n  assert,\n  assertEquals,\n  assertStringIncludes,\n} from \"https://deno.land/std@0.126.0/testing/asserts.ts\";\n```\n\nyou can refer to the explanation of this convention here\nhttps://docs.deno.com/runtime/manual/basics/modules/#it-seems-unwieldy-to-import-urls-everywhere\n",
    "tags": []
  },
  {
    "code": "no-extra-boolean-cast",
    "docs": "Disallows unnecessary boolean casts\n\nIn certain contexts, such as `if`, `while` or `for` statements, expressions are\nautomatically coerced into a boolean. Therefore, techniques such as double\nnegation (`!!foo`) or casting (`Boolean(foo)`) are unnecessary and produce the\nsame result as without the negation or casting.\n\n### Invalid:\n\n```typescript\nif (!!foo) {}\nif (Boolean(foo)) {}\nwhile (!!foo) {}\nfor (; Boolean(foo);) {}\n```\n\n### Valid:\n\n```typescript\nif (foo) {}\nwhile (foo) {}\nfor (; foo;) {}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-extra-non-null-assertion",
    "docs": "Disallows unnecessary non-null assertions\n\nNon-null assertions are specified with an `!` saying to the compiler that you\nknow this value is not null. Specifying this operator more than once in a row,\nor in combination with the optional chaining operator (`?`) is confusing and\nunnecessary.\n\n### Invalid:\n\n```typescript\nconst foo: { str: string } | null = null;\nconst bar = foo!!.str;\n\nfunction myFunc(bar: undefined | string) {\n  return bar!!;\n}\nfunction anotherFunc(bar?: { str: string }) {\n  return bar!?.str;\n}\n```\n\n### Valid:\n\n```typescript\nconst foo: { str: string } | null = null;\nconst bar = foo!.str;\n\nfunction myFunc(bar: undefined | string) {\n  return bar!;\n}\nfunction anotherFunc(bar?: { str: string }) {\n  return bar?.str;\n}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-fallthrough",
    "docs": "Disallows the implicit fallthrough of case statements\n\nCase statements without a `break` will execute their body and then fallthrough\nto the next case or default block and execute this block as well. While this is\nsometimes intentional, many times the developer has forgotten to add a break\nstatement, intending only for a single case statement to be executed. This rule\nenforces that you either end each case statement with a break statement or an\nexplicit comment that fallthrough was intentional. The fallthrough comment must\ncontain one of `fallthrough`, `falls through` or `fall through`.\n\n### Invalid:\n\n```typescript\nswitch (myVar) {\n  case 1:\n    console.log(\"1\");\n\n  case 2:\n    console.log(\"2\");\n}\n// If myVar = 1, outputs both `1` and `2`.  Was this intentional?\n```\n\n### Valid:\n\n```typescript\nswitch (myVar) {\n  case 1:\n    console.log(\"1\");\n    break;\n\n  case 2:\n    console.log(\"2\");\n    break;\n}\n// If myVar = 1, outputs only `1`\n\nswitch (myVar) {\n  case 1:\n    console.log(\"1\");\n    /* falls through */\n  case 2:\n    console.log(\"2\");\n}\n// If myVar = 1, intentionally outputs both `1` and `2`\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-func-assign",
    "docs": "Disallows the overwriting/reassignment of an existing function\n\nJavascript allows for the reassignment of a function definition. This is\ngenerally a mistake on the developers part, or poor coding practice as code\nreadability and maintainability will suffer.\n\n### Invalid:\n\n```typescript\nfunction foo() {}\nfoo = bar;\n\nconst a = function baz() {\n  baz = \"now I'm a string\";\n};\n\nmyFunc = existingFunc;\nfunction myFunc() {}\n```\n\n### Valid:\n\n```typescript\nfunction foo() {}\nconst someVar = foo;\n\nconst a = function baz() {\n  const someStr = \"now I'm a string\";\n};\n\nconst anotherFuncRef = existingFunc;\n\nlet myFuncVar = function () {};\nmyFuncVar = bar; // variable reassignment, not function re-declaration\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-global-assign",
    "docs": "Disallows assignment to native Javascript objects\n\nIn Javascript, `String` and `Object` for example are native objects. Like any\nobject, they can be reassigned, but it is almost never wise to do so as this can\nlead to unexpected results and difficult to track down bugs.\n\n### Invalid:\n\n```typescript\nObject = null;\nundefined = true;\nwindow = {};\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-implicit-declare-namespace-export",
    "docs": "Disallows the use of implicit exports in [\"ambient\" namespaces].\n\nTypeScript implicitly export all members of an [\"ambient\" namespaces], except\nwhether a named export is present.\n\n[\"ambient\" namespaces]: https://www.typescriptlang.org/docs/handbook/namespaces.html#ambient-namespaces\n\n### Invalid:\n\n```ts\n// foo.ts or foo.d.ts\ndeclare namespace ns {\n  interface ImplicitlyExported {}\n  export type Exported = true;\n}\n```\n\n### Valid:\n\n```ts\n// foo.ts or foo.d.ts\ndeclare namespace ns {\n  interface NonExported {}\n  export {};\n}\n\ndeclare namespace ns {\n  interface Exported {}\n  export { Exported };\n}\n\ndeclare namespace ns {\n  export interface Exported {}\n}\n```\n",
    "tags": []
  },
  {
    "code": "no-import-assertions",
    "docs": "Disallows the `assert` keyword for import attributes\n\nES import attributes (previously called import assertions) has been changed to\nuse the `with` keyword. The old syntax using `assert` is still supported, but\ndeprecated.\n\n### Invalid:\n\n```typescript\nimport obj from \"./obj.json\" assert { type: \"json\" };\nimport(\"./obj2.json\", { assert: { type: \"json\" } });\n```\n\n### Valid:\n\n```typescript\nimport obj from \"./obj.json\" with { type: \"json\" };\nimport(\"./obj2.json\", { with: { type: \"json\" } });\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-import-assign",
    "docs": "Disallows reassignment of imported module bindings\n\nES module import bindings should be treated as read-only since modifying them\nduring code execution will likely result in runtime errors. It also makes for\npoor code readability and difficult maintenance.\n\n### Invalid:\n\n```typescript\nimport defaultMod, { namedMod } from \"./mod.js\";\nimport * as modNameSpace from \"./mod2.js\";\n\ndefaultMod = 0;\nnamedMod = true;\nmodNameSpace.someExportedMember = \"hello\";\nmodNameSpace = {};\n```\n\n### Valid:\n\n```typescript\nimport defaultMod, { namedMod } from \"./mod.js\";\nimport * as modNameSpace from \"./mod2.js\";\n\n// properties of bound imports may be set\ndefaultMod.prop = 1;\nnamedMod.prop = true;\nmodNameSpace.someExportedMember.prop = \"hello\";\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-inferrable-types",
    "docs": "Disallows easily inferrable types\n\nVariable initializations to JavaScript primitives (and `null`) are obvious in\ntheir type. Specifying their type can add additional verbosity to the code. For\nexample, with `const x: number = 5`, specifying `number` is unnecessary as it is\nobvious that `5` is a number.\n\n### Invalid:\n\n```typescript\nconst a: bigint = 10n;\nconst b: bigint = BigInt(10);\nconst c: boolean = true;\nconst d: boolean = !0;\nconst e: number = 10;\nconst f: number = Number(\"1\");\nconst g: number = Infinity;\nconst h: number = NaN;\nconst i: null = null;\nconst j: RegExp = /a/;\nconst k: RegExp = RegExp(\"a\");\nconst l: RegExp = new RegExp(\"a\");\nconst m: string = \"str\";\nconst n: string = `str`;\nconst o: string = String(1);\nconst p: symbol = Symbol(\"a\");\nconst q: undefined = undefined;\nconst r: undefined = void someValue;\n\nclass Foo {\n  prop: number = 5;\n}\n\nfunction fn(s: number = 5, t: boolean = true) {}\n```\n\n### Valid:\n\n```typescript\nconst a = 10n;\nconst b = BigInt(10);\nconst c = true;\nconst d = !0;\nconst e = 10;\nconst f = Number(\"1\");\nconst g = Infinity;\nconst h = NaN;\nconst i = null;\nconst j = /a/;\nconst k = RegExp(\"a\");\nconst l = new RegExp(\"a\");\nconst m = \"str\";\nconst n = `str`;\nconst o = String(1);\nconst p = Symbol(\"a\");\nconst q = undefined;\nconst r = void someValue;\n\nclass Foo {\n  prop = 5;\n}\n\nfunction fn(s = 5, t = true) {}\n```\n",
    "tags": []
  },
  {
    "code": "no-inner-declarations",
    "docs": "Disallows variable or function definitions in nested blocks\n\nFunction declarations in nested blocks can lead to less readable code and\npotentially unexpected results due to compatibility issues in different\nJavaScript runtimes. This does not apply to named or anonymous functions which\nare valid in a nested block context.\n\nVariables declared with `var` in nested blocks can also lead to less readable\ncode. Because these variables are hoisted to the module root, it is best to\ndeclare them there for clarity. Note that variables declared with `let` or\n`const` are block scoped and therefore this rule does not apply to them.\n\n### Invalid:\n\n```typescript\nif (someBool) {\n  function doSomething() {}\n}\n\nfunction someFunc(someVal: number): void {\n  if (someVal > 4) {\n    var a = 10;\n  }\n}\n```\n\n### Valid:\n\n```typescript\nfunction doSomething() {}\nif (someBool) {}\n\nvar a = 10;\nfunction someFunc(someVal: number): void {\n  var foo = true;\n  if (someVal > 4) {\n    let b = 10;\n    const fn = function doSomethingElse() {};\n  }\n}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-invalid-regexp",
    "docs": "Disallows specifying invalid regular expressions in RegExp constructors\n\nSpecifying an invalid regular expression literal will result in a SyntaxError at\ncompile time, however specifying an invalid regular expression string in the\nRegExp constructor will only be discovered at runtime.\n\n### Invalid:\n\n```typescript\nconst invalidRegExp = new RegExp(\")\");\n```\n\n### Valid:\n\n```typescript\nconst goodRegExp = new RegExp(\".\");\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-invalid-triple-slash-reference",
    "docs": "Warns the wrong usage of triple-slash reference directives.\n\nDeno supports the triple-slash reference directives of `types`, `path`, `lib`,\nand `no-default-lib`. This lint rule checks if there is an invalid, badly-formed\ndirective because it is most likely a mistake.\n\nAdditionally, note that only the `types` directive is allowed in JavaScript\nfiles. This directive is useful for telling the TypeScript compiler the location\nof a type definition file that corresponds to a certain JavaScript file.\nHowever, even in the Deno manual of the versions prior to v1.10 (e.g. [v1.9.2]),\nthere was a wrong statement describing that one should use the `path` directive\nin such cases. Actually, the `types` directive should be used. See\n[the latest manual] for more detail. So this rule also detects the usage of the\ndirective other than `types` in JavaScript files and suggests replacing it with\nthe `types` directive.\n\n[v1.9.2]: https://deno.land/manual@v1.9.2/typescript/types#using-the-triple-slash-reference-directive\n[the latest manual]: https://deno.land/manual/typescript/types#using-the-triple-slash-reference-directive\n\n### Invalid:\n\n#### JavaScript\n\n```javascript\n/// <reference path=\"./mod.d.ts\" />\n/// <reference no-default-lib=\"true\" />\n/// <reference foo=\"bar\" />\n\n// ... the rest of the JavaScript ...\n```\n\n#### TypeScript\n\n```typescript\n/// <reference foo=\"bar\" />\n\n// ... the rest of the TypeScript ...\n```\n\n### Valid:\n\n#### JavaScript\n\n```javascript\n/// <reference types=\"./mod.d.ts\" />\n/// <reference lib=\"es2017.string\" />\n\n// ... the rest of the JavaScript ...\n```\n\n#### TypeScript\n\n```typescript\n/// <reference types=\"./mod.d.ts\" />\n/// <reference path=\"./mod.d.ts\" />\n/// <reference lib=\"es2017.string\" />\n/// <reference no-default-lib=\"true\" />\n\n// ... the rest of the TypeScript ...\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-irregular-whitespace",
    "docs": "Disallows the use of non-space or non-tab whitespace characters\n\nNon-space or non-tab whitespace characters can be very difficult to spot in your\ncode as editors will often render them invisibly. These invisible characters can\ncause issues or unexpected behaviors. Sometimes these characters are added\ninadvertently through copy/paste or incorrect keyboard shortcuts.\n\nThe following characters are disallowed:\n\n```\n\\u000B - Line Tabulation (\\v) - <VT>\n\\u000C - Form Feed (\\f) - <FF>\n\\u00A0 - No-Break Space - <NBSP>\n\\u0085 - Next Line\n\\u1680 - Ogham Space Mark\n\\u180E - Mongolian Vowel Separator - <MVS>\n\\ufeff - Zero Width No-Break Space - <BOM>\n\\u2000 - En Quad\n\\u2001 - Em Quad\n\\u2002 - En Space - <ENSP>\n\\u2003 - Em Space - <EMSP>\n\\u2004 - Tree-Per-Em\n\\u2005 - Four-Per-Em\n\\u2006 - Six-Per-Em\n\\u2007 - Figure Space\n\\u2008 - Punctuation Space - <PUNCSP>\n\\u2009 - Thin Space\n\\u200A - Hair Space\n\\u200B - Zero Width Space - <ZWSP>\n\\u2028 - Line Separator\n\\u2029 - Paragraph Separator\n\\u202F - Narrow No-Break Space\n\\u205f - Medium Mathematical Space\n\\u3000 - Ideographic Space\n```\n\nTo fix this linting issue, replace instances of the above with regular spaces,\ntabs or new lines. If it's not obvious where the offending character(s) are try\nretyping the line from scratch.\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-legacy-type-assertion",
    "docs": "Disallows the use of legacy `<Type> value` type assertion syntax in TypeScript\ncode.\n\n`<Type> value` casting syntax is considered to be outdated because it does not\nwork in JSX. Instead, you should use `value as Type`.\n\n### Invalid:\n\n```typescript\nconst foo = <Foo> bar;\n```\n\n### Valid:\n\n```typescript\nconst foo = bar as Foo;\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-misused-new",
    "docs": "Disallows defining `constructor`s for interfaces or `new` for classes\n\nSpecifying a `constructor` for an interface or defining a `new` method for a\nclass is incorrect and should be avoided.\n\n### Invalid:\n\n```typescript\nclass C {\n  new(): C;\n}\n\ninterface I {\n  constructor(): void;\n}\n```\n\n### Valid:\n\n```typescript\nclass C {\n  constructor() {}\n}\n\ninterface I {\n  new (): C;\n}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-namespace",
    "docs": "Disallows the use of `namespace` and `module` keywords in TypeScript code.\n\n`namespace` and `module` are both thought of as outdated keywords to organize\nthe code. Instead, it is generally preferable to use ES2015 module syntax (e.g.\n`import`/`export`).\n\nHowever, this rule still allows the use of these keywords in the following two\ncases:\n\n- they are used for defining [\"ambient\" namespaces] along with `declare`\n  keywords\n- they are written in TypeScript's type definition files: `.d.ts`\n\n[\"ambient\" namespaces]: https://www.typescriptlang.org/docs/handbook/namespaces.html#ambient-namespaces\n\n### Invalid:\n\n```typescript\n// foo.ts\nmodule mod {}\nnamespace ns {}\n```\n\n```dts\n// bar.d.ts\n// all usage of `module` and `namespace` keywords are allowed in `.d.ts`\n```\n\n### Valid:\n\n```typescript\n// foo.ts\ndeclare global {}\ndeclare module mod1 {}\ndeclare module \"mod2\" {}\ndeclare namespace ns {}\n```\n\n```dts\n// bar.d.ts\nmodule mod1 {}\nnamespace ns1 {}\ndeclare global {}\ndeclare module mod2 {}\ndeclare module \"mod3\" {}\ndeclare namespace ns2 {}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-new-symbol",
    "docs": "Disallows the use of `new` operators with built-in `Symbol`s\n\n`Symbol`s are created by being called as a function, but we sometimes call it\nwith the `new` operator by mistake. This rule detects such wrong usage of the\n`new` operator.\n\n### Invalid:\n\n```typescript\nconst foo = new Symbol(\"foo\");\n```\n\n### Valid:\n\n```typescript\nconst foo = Symbol(\"foo\");\n\nfunction func(Symbol: typeof SomeClass) {\n  // This `Symbol` is not built-in one\n  const bar = new Symbol();\n}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-node-globals",
    "docs": "Disallows the use of NodeJS global objects.\n\nNodeJS exposes a set of global objects that differs from deno (and the web), so\ncode should not assume they are available. Instead, import the objects from\ntheir defining modules as needed.\n\n### Invalid:\n\n```typescript\n// foo.ts\nconst foo = process.env.FOO; // process is not a global object in deno\n```\n\n### Valid:\n\n```typescript\n// foo.ts\nimport process from \"node:process\";\n\nconst foo = process.env.FOO;\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-non-null-asserted-optional-chain",
    "docs": "Disallow non-null assertions after an optional chain expression\n\n`?.` optional chain expressions provide undefined if an object is `null` or\n`undefined`. Using a `!` non-null assertion to assert the result of an `?.`\noptional chain expression is non-nullable is likely wrong.\n\n### Invalid:\n\n```typescript\nfoo?.bar!;\nfoo?.bar()!;\n```\n\n### Valid:\n\n```typescript\nfoo?.bar;\nfoo?.bar();\n```\n",
    "tags": []
  },
  {
    "code": "no-non-null-assertion",
    "docs": "Disallow non-null assertions using the `!` postfix operator\n\nTypeScript's `!` non-null assertion operator asserts to the type system that an\nexpression is non-nullable, as in not `null` or `undefined`. Using assertions to\ntell the type system new information is often a sign that code is not fully\ntype-safe. It's generally better to structure program logic so that TypeScript\nunderstands when values may be nullable.\n\n### Invalid:\n\n```typescript\ninterface Example {\n  property?: string;\n}\ndeclare const example: Example;\n\nconst includes = example.property!.includes(\"foo\");\n```\n\n### Valid:\n\n```typescript\ninterface Example {\n  property?: string;\n}\ndeclare const example: Example;\n\nconst includes = example.property?.includes(\"foo\") ?? false;\n```\n",
    "tags": []
  },
  {
    "code": "no-obj-calls",
    "docs": "Disallows calling built-in global objects like functions\n\nThe following built-in objects should not be invoked like functions, even though\nthey look like constructors:\n\n- `Math`\n- `JSON`\n- `Reflect`\n- `Atomics`\n\nCalling these as functions would result in runtime errors. This rule statically\nprevents such wrong usage of them.\n\n### Invalid:\n\n```typescript\nconst math = Math();\nconst newMath = new Math();\n\nconst json = JSON();\nconst newJSON = new JSON();\n\nconst reflect = Reflect();\nconst newReflect = new Reflect();\n\nconst atomics = Atomics();\nconst newAtomics = new Atomics();\n```\n\n### Valid:\n\n```typescript\nconst area = (radius: number): number => Math.PI * radius * radius;\n\nconst parsed = JSON.parse(\"{ foo: 42 }\");\n\nconst x = Reflect.get({ x: 1, y: 2 }, \"x\");\n\nconst first = Atomics.load(foo, 0);\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-octal",
    "docs": "Disallows expressing octal numbers via numeric literals beginning with `0`\n\nOctal numbers can be expressed via numeric literals with leading `0` like `042`,\nbut this expression often confuses programmers. That's why ECMAScript's strict\nmode throws `SyntaxError` for the expression.\n\nSince ES2015, the other prefix `0o` has been introduced as an alternative. This\nnew one is always encouraged to use in today's code.\n\n### Invalid:\n\n```typescript\nconst a = 042;\nconst b = 7 + 042;\n```\n\n### Valid:\n\n```typescript\nconst a = 0o42;\nconst b = 7 + 0o42;\nconst c = \"042\";\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-prototype-builtins",
    "docs": "Disallows the use of `Object.prototype` builtins directly\n\nIf objects are created via `Object.create(null)` they have no prototype\nspecified. This can lead to runtime errors when you assume objects have\nproperties from `Object.prototype` and attempt to call the following methods:\n\n- `hasOwnProperty`\n- `isPrototypeOf`\n- `propertyIsEnumerable`\n\nInstead, it's always encouraged to call these methods from `Object.prototype`\nexplicitly.\n\n### Invalid:\n\n```typescript\nconst a = foo.hasOwnProperty(\"bar\");\nconst b = foo.isPrototypeOf(\"bar\");\nconst c = foo.propertyIsEnumerable(\"bar\");\n```\n\n### Valid:\n\n```typescript\nconst a = Object.prototype.hasOwnProperty.call(foo, \"bar\");\nconst b = Object.prototype.isPrototypeOf.call(foo, \"bar\");\nconst c = Object.prototype.propertyIsEnumerable.call(foo, \"bar\");\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-redeclare",
    "docs": "Disallows redeclaration of variables, functions, parameters with the same name.\n\nJavaScript allows us to redeclare variables with the same name using `var`, but\nredeclaration should not be used since it can make variables hard to trace.\n\nIn addition, this lint rule disallows redeclaration using `let` or `const` as\nwell, although ESLint allows. This is useful because we can notice a syntax\nerror before actually running the code.\n\nAs for functions and parameters, JavaScript just treats these as runtime errors,\nthrowing `SyntaxError` when being run. It's also beneficial to detect this sort\nof errors statically.\n\n### Invalid:\n\n```typescript\nvar a = 3;\nvar a = 10;\n\nlet b = 3;\nlet b = 10;\n\nconst c = 3;\nconst c = 10;\n\nfunction d() {}\nfunction d() {}\n\nfunction e(arg: number) {\n  var arg: number;\n}\n\nfunction f(arg: number, arg: string) {}\n```\n\n### Valid:\n\n```typescript\nvar a = 3;\nfunction f() {\n  var a = 10;\n}\n\nif (foo) {\n  let b = 2;\n} else {\n  let b = 3;\n}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-regex-spaces",
    "docs": "Disallows multiple spaces in regular expression literals.\n\nMultiple spaces in regular expression literals are generally hard to read when\nthe regex gets complicated. Instead, it's better to use only one space character\nand specify how many times spaces should appear with the `{n}` syntax, for\nexample:\n\n```typescript\n// Multiple spaces in the regex literal are harder to understand how many\n// spaces are expected to be matched\nconst re = /foo   bar/;\n\n// Instead use `{n}` syntax for readability\nconst re = /foo {3}var/;\n```\n\n### Invalid:\n\n```typescript\nconst re1 = /  /;\nconst re2 = /foo  bar/;\nconst re3 = / a b  c d /;\nconst re4 = /foo  {3}bar/;\n\nconst re5 = new RegExp(\"  \");\nconst re6 = new RegExp(\"foo  bar\");\nconst re7 = new RegExp(\" a b  c d \");\nconst re8 = new RegExp(\"foo  {3}bar\");\n```\n\n### Valid:\n\n```typescript\nconst re1 = /foo/;\nconst re2 = / /;\nconst re3 = / {3}/;\nconst re4 = / +/;\nconst re5 = / ?/;\nconst re6 = / */;\n\nconst re7 = new RegExp(\"foo\");\nconst re8 = new RegExp(\" \");\nconst re9 = new RegExp(\" {3}\");\nconst re10 = new RegExp(\" +\");\nconst re11 = new RegExp(\" ?\");\nconst re12 = new RegExp(\" *\");\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-self-assign",
    "docs": "Disallows self assignments\n\nSelf assignments like `a = a;` have no effect at all. If there are self\nassignments in the code, most likely it means that the author is still in the\nprocess of refactoring and there's remaining work they have to do.\n\n### Invalid:\n\n```typescript\na = a;\n[a] = [a];\n[a, b] = [a, b];\n[a, b] = [a, c];\n[a, ...b] = [a, ...b];\na.b = a.b;\n```\n\n### Valid:\n\n```typescript\nlet a = a;\na += a;\na = [a];\n[a, b] = [b, a];\na.b = a.c;\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-self-compare",
    "docs": "Disallows comparisons where both sides are exactly the same.\n\nComparing a variable or value against itself is usually an error, either a typo\nor refactoring error. It is confusing to the reader and may potentially\nintroduce a runtime error.\n\n### Invalid:\n\n```typescript\nif (x === x) {\n}\nif (\"x\" === \"x\") {\n}\nif (a.b === a.b) {\n}\nif (a[\"b\"] === a[\"b\"]) {\n}\n```\n\n### Valid:\n\n```typescript\nif (x === y) {\n}\nif (\"x\" === \"y\") {\n}\nif (a.b === a.c) {\n}\nif (a[\"b\"] === a[\"c\"]) {\n}\n```\n",
    "tags": []
  },
  {
    "code": "no-setter-return",
    "docs": "Disallows returning values from setters.\n\nSetters are supposed to be used for setting some value to the property, which\nmeans that returning a value from a setter makes no sense. In fact, returned\nvalues are ignored and cannot ever be used at all although returning a value\nfrom a setter produces no error. This is why static check for this mistake by\nthe linter is quite beneficial.\n\nNote that returning without a value is allowed; this is a useful technique to do\nearly-return from a function.\n\n### Invalid:\n\n```typescript\nconst a = {\n  set foo(x: number) {\n    return \"something\";\n  },\n};\n\nclass B {\n  private set foo(x: number) {\n    return \"something\";\n  }\n}\n\nconst c = {\n  set foo(x: boolean) {\n    if (x) {\n      return 42;\n    }\n  },\n};\n```\n\n### Valid:\n\n```typescript\n// return without a value is allowed since it is used to do early-return\nconst a = {\n  set foo(x: number) {\n    if (x % 2 == 0) {\n      return;\n    }\n  },\n};\n\n// not a setter, but a getter\nclass B {\n  get foo() {\n    return 42;\n  }\n}\n\n// not a setter\nconst c = {\n  set(x: number) {\n    return \"something\";\n  },\n};\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-shadow-restricted-names",
    "docs": "Disallows shadowing of restricted names.\n\nThe following (a) properties of the global object, or (b) identifiers are\n\"restricted\" names in JavaScript:\n\n- [`NaN`]\n- [`Infinity`]\n- [`undefined`]\n- [`eval`]\n- [`arguments`]\n\nThese names are _NOT_ reserved in JavaScript, which means that nothing prevents\none from assigning other values into them (i.e. shadowing). In other words, you\nare allowed to use, say, `undefined` as an identifier or variable name. (For\nmore details see [MDN])\n\n[`NaN`]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN\n[`Infinity`]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Infinity\n[`undefined`]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/undefined\n[`eval`]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval\n[`arguments`]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/arguments\n[MDN]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/undefined#description\n\n```typescript\nfunction foo() {\n  const undefined = \"bar\";\n  console.log(undefined); // output: \"bar\"\n}\n```\n\nOf course, shadowing like this most likely confuse other developers and should\nbe avoided. This lint rule detects and warn them.\n\n### Invalid:\n\n```typescript\nconst undefined = 42;\n\nfunction NaN() {}\n\nfunction foo(Infinity) {}\n\nconst arguments = () => {};\n\ntry {\n} catch (eval) {}\n```\n\n### Valid:\n\n```typescript\n// If not assigned a value, `undefined` may be shadowed\nconst undefined;\n\nconst Object = 42;\n\nfunction foo(a: number, b: string) {}\n\ntry {\n} catch (e) {}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-sparse-arrays",
    "docs": "Disallows sparse arrays\n\nSparse arrays are arrays that contain _empty slots_, which later could be\nhandled either as `undefined` value or skipped by array methods, and this may\nlead to unexpected behavior:\n\n```typescript\n[1, , 2].join(); // => '1,,2'\n[1, undefined, 2].join(); // => '1,,2'\n\n[1, , 2].flatMap((item) => item); // => [1, 2]\n[1, undefined, 2].flatMap((item) => item); // => [1, undefined, 2]\n```\n\n### Invalid:\n\n```typescript\nconst items = [\"foo\", , \"bar\"];\n```\n\n### Valid:\n\n```typescript\nconst items = [\"foo\", \"bar\"];\n```\n",
    "tags": []
  },
  {
    "code": "no-sync-fn-in-async-fn",
    "docs": "Disallow sync function inside async function\n\nUsing sync functions like `Deno.readTextFileSync` blocks the deno event loop so\nit's not recommended to use it inside of an async function, because it stops\nprogress of all other async tasks.\n\n### Invalid:\n\n```javascript\nasync function foo() {\n  Deno.readTextFileSync(\"\");\n}\n\nconst fooFn = async function foo() {\n  Deno.readTextFileSync(\"\");\n};\n\nconst fooFn = async () => {\n  Deno.readTextFileSync(\"\");\n};\n```\n\n### Valid:\n\n```javascript\nasync function foo() {\n  await Deno.readTextFile(\"\");\n}\n\nfunction foo() {\n  Deno.readTextFileSync(\"\");\n}\n\nconst fooFn = function foo() {\n  Deno.readTextFileSync(\"\");\n};\n\nconst fooFn = () => {\n  Deno.readTextFileSync(\"\");\n};\n```\n",
    "tags": []
  },
  {
    "code": "no-this-alias",
    "docs": "Disallows assigning variables to `this`.\n\nIn most cases, storing a reference to `this` in a variable could be avoided by\nusing arrow functions properly, since they establish `this` based on the scope\nwhere the arrow function is defined.\n\nLet's take a look at a concrete example:\n\n```typescript\nconst obj = {\n  count: 0,\n  doSomethingLater() {\n    setTimeout(function () { // this function executes on the global scope; `this` evalutes to `globalThis`\n      this.count++;\n      console.log(this.count);\n    }, 300);\n  },\n};\n\nobj.doSomethingLater();\n// `NaN` is printed, because the property `count` is not in the global scope.\n```\n\nIn the above example, `this` in the function passed to `setTimeout` evaluates to\n`globalThis`, which results in the expected value `1` not being printed.\n\nIf you wanted to work around it without arrow functions, you would store a\nreference to `this` in another variable:\n\n```typescript\nconst obj = {\n  count: 0,\n  doSomethingLater() {\n    const self = this; // store a reference to `this` in `self`\n    setTimeout(function () {\n      // use `self` instead of `this`\n      self.count++;\n      console.log(self.count);\n    }, 300);\n  },\n};\n\nobj.doSomethingLater();\n// `1` is printed as expected\n```\n\nBut in this case arrow functions come in handy. With arrow functions, the code\nbecomes way clearer and easier to understand:\n\n```typescript\nconst obj = {\n  count: 0,\n  doSomethingLater() {\n    setTimeout(() => { // pass an arrow function\n      // `this` evaluates to `obj` here\n      this.count++;\n      console.log(this.count);\n    }, 300);\n  },\n};\n\nobj.doSomethingLater();\n// `1` is printed as expected\n```\n\nThis example is taken from\n[MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions).\n\n### Invalid:\n\n```typescript\nconst self = this;\n\nfunction foo() {\n  const self = this;\n}\n\nconst bar = () => {\n  const self = this;\n};\n```\n\n### Valid:\n\n```typescript\nconst self = \"this\";\n\nconst [foo] = this;\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-this-before-super",
    "docs": "Disallows use of `this` or `super` before calling `super()` in constructors.\n\nThe access to `this` or `super` before calling `super()` in the constructor of\nderived classes leads to [`ReferenceError`]. To prevent it, this lint rule\nchecks if there are accesses to `this` or `super` before calling `super()` in\nconstructors.\n\n[`ReferenceError`]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ReferenceError\n\n### Invalid:\n\n```typescript\nclass A extends B {\n  constructor() {\n    this.foo = 0;\n    super();\n  }\n}\n\nclass C extends D {\n  constructor() {\n    super.foo();\n    super();\n  }\n}\n```\n\n### Valid:\n\n```typescript\nclass A extends B {\n  constructor() {\n    super();\n    this.foo = 0;\n  }\n}\n\nclass C extends D {\n  constructor() {\n    super();\n    super.foo();\n  }\n}\n\nclass E {\n  constructor() {\n    this.foo = 0;\n  }\n}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-throw-literal",
    "docs": "Disallow throwing literals as exceptions\n\nIt is considered good practice to only `throw` the `Error` object itself or an\nobject using the `Error` object as base objects for user-defined exceptions. The\nfundamental benefit of `Error` objects is that they automatically keep track of\nwhere they were built and originated.\n\n### Invalid:\n\n```typescript\nthrow \"error\";\nthrow 0;\nthrow undefined;\nthrow null;\n```\n\n### Valid:\n\n```typescript\nthrow new Error(\"error\");\n```\n",
    "tags": []
  },
  {
    "code": "no-top-level-await",
    "docs": "Disallows the use of top level await expressions.\n\nTop level await cannot be used when distributing CommonJS/UMD via dnt.\n\n### Invalid:\n\n```typescript\nawait foo();\nfor await (item of items) {}\n```\n\n### Valid:\n\n```typescript\nasync function foo() {\n  await task();\n}\nasync function foo() {\n  for await (item of items) {}\n}\n```\n",
    "tags": []
  },
  {
    "code": "no-undef",
    "docs": "Disallow the use of undeclared variables\n\n### Invalid:\n\n```typescript\nconst foo = someFunction();\nconst bar = a + 1;\n```\n",
    "tags": []
  },
  {
    "code": "no-unreachable",
    "docs": "Disallows the unreachable code after the control flow statements.\n\nBecause the control flow statements (`return`, `throw`, `break` and `continue`)\nunconditionally exit a block of code, any statements after them cannot be\nexecuted.\n\n### Invalid:\n\n```typescript\nfunction foo() {\n  return true;\n  console.log(\"done\");\n}\n```\n\n```typescript\nfunction bar() {\n  throw new Error(\"Oops!\");\n  console.log(\"done\");\n}\n```\n\n```typescript\nwhile (value) {\n  break;\n  console.log(\"done\");\n}\n```\n\n```typescript\nthrow new Error(\"Oops!\");\nconsole.log(\"done\");\n```\n\n```typescript\nfunction baz() {\n  if (Math.random() < 0.5) {\n    return;\n  } else {\n    throw new Error();\n  }\n  console.log(\"done\");\n}\n```\n\n```typescript\nfor (;;) {}\nconsole.log(\"done\");\n```\n\n### Valid\n\n```typescript\nfunction foo() {\n  return bar();\n  function bar() {\n    return 1;\n  }\n}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-unsafe-finally",
    "docs": "Disallows the use of control flow statements within `finally` blocks.\n\nUse of the control flow statements (`return`, `throw`, `break` and `continue`)\noverrides the usage of any control flow statements that might have been used in\nthe `try` or `catch` blocks, which is usually not the desired behaviour.\n\n### Invalid:\n\n```typescript\nlet foo = function () {\n  try {\n    return 1;\n  } catch (err) {\n    return 2;\n  } finally {\n    return 3;\n  }\n};\n```\n\n```typescript\nlet foo = function () {\n  try {\n    return 1;\n  } catch (err) {\n    return 2;\n  } finally {\n    throw new Error();\n  }\n};\n```\n\n### Valid:\n\n```typescript\nlet foo = function () {\n  try {\n    return 1;\n  } catch (err) {\n    return 2;\n  } finally {\n    console.log(\"hola!\");\n  }\n};\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-unsafe-negation",
    "docs": "Disallows the usage of negation operator `!` as the left operand of relational\noperators.\n\n`!` operators appearing in the left operand of the following operators will\nsometimes cause an unexpected behavior because of the operator precedence:\n\n- `in` operator\n- `instanceof` operator\n\nFor example, when developers write a code like `!key in someObject`, most likely\nthey want it to behave just like `!(key in someObject)`, but actually it behaves\nlike `(!key) in someObject`. This lint rule warns such usage of `!` operator so\nit will be less confusing.\n\n### Invalid:\n\n<!-- deno-fmt-ignore -->\n\n```typescript\nif (!key in object) {}\nif (!foo instanceof Foo) {}\n```\n\n### Valid:\n\n```typescript\nif (!(key in object)) {}\nif (!(foo instanceof Foo)) {}\nif ((!key) in object) {}\nif ((!foo) instanceof Foo) {}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-unused-labels",
    "docs": "Disallows unused labels.\n\nA label that is declared but never used is most likely developer's mistake. If\nthat label is meant to be used, then write a code so that it will be used.\nOtherwise, remove the label.\n\n### Invalid:\n\n```typescript\nLABEL1:\nwhile (true) {\n  console.log(42);\n}\n\nLABEL2:\nfor (let i = 0; i < 5; i++) {\n  console.log(42);\n}\n\nLABEL3:\nfor (const x of xs) {\n  console.log(x);\n}\n```\n\n### Valid:\n\n```typescript\nLABEL1:\nwhile (true) {\n  console.log(42);\n  break LABEL1;\n}\n\nLABEL2:\nfor (let i = 0; i < 5; i++) {\n  console.log(42);\n  continue LABEL2;\n}\n\nfor (const x of xs) {\n  console.log(x);\n}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-unused-vars",
    "docs": "Enforces all variables are used at least once.\n\nIf there are variables that are declared but not used anywhere, it's most likely\nbecause of incomplete refactoring. This lint rule detects and warns such unused\nvariables.\n\nVariable `a` is considered to be \"used\" if any of the following conditions are\nsatisfied:\n\n- its value is read out, like `console.log(a)` or `let otherVariable = a;`\n- it's called or constructed, like `a()` or `new a()`\n- it's exported, like `export const a = 42;`\n\nIf a variable is just assigned to a value but never read out, then it's\nconsidered to be _\"not used\"_.\n\n```typescript\nlet a;\na = 42;\n\n// `a` is never read out\n```\n\nIf you want to declare unused variables intentionally, prefix them with the\nunderscore character `_`, like `_a`. This rule ignores variables that are\nprefixed with `_`.\n\n### Invalid:\n\n```typescript\nconst a = 0;\n\nconst b = 0; // this `b` is never used\nfunction foo() {\n  const b = 1; // this `b` is used\n  console.log(b);\n}\nfoo();\n\nlet c = 2;\nc = 3;\n\n// recursive function calls are not considered to be used, because only when `d`\n// is called from outside the function body can we say that `d` is actually\n// called after all.\nfunction d() {\n  d();\n}\n\n// `x` is never used\nexport function e(x: number): number {\n  return 42;\n}\n\nconst f = \"unused variable\";\n```\n\n### Valid:\n\n```typescript\nconst a = 0;\nconsole.log(a);\n\nconst b = 0;\nfunction foo() {\n  const b = 1;\n  console.log(b);\n}\nfoo();\nconsole.log(b);\n\nlet c = 2;\nc = 3;\nconsole.log(c);\n\nfunction d() {\n  d();\n}\nd();\n\nexport function e(x: number): number {\n  return x + 42;\n}\n\nexport const f = \"exported variable\";\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-var",
    "docs": "Enforces the use of block scoped variables over more error prone function scoped\nvariables. Block scoped variables are defined using `const` and `let` keywords.\n\n`const` and `let` keywords ensure the variables defined using these keywords are\nnot accessible outside their block scope. On the other hand, variables defined\nusing `var` keyword are only limited by their function scope.\n\n### Invalid:\n\n```typescript\nvar foo = \"bar\";\n```\n\n### Valid:\n\n```typescript\nconst foo = 1;\nlet bar = 2;\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-window",
    "docs": "Disallows the use of the `window` object.\n\nUsing the `window` global is deprecated and scheduled for removal in Deno 2.0.\nDeno does not have a window and `typeof window === \"undefined\"` is often used to\ntell if the code is running in the browser.\n\n### Invalid:\n\n```typescript\nconst a = await window.fetch(\"https://deno.land\");\n\nconst b = window.Deno.metrics();\nconsole.log(window);\n\nwindow.addEventListener(\"load\", () => {\n  console.log(\"Loaded.\");\n});\n```\n\n### Valid:\n\n```typescript\nconst a1 = await fetch(\"https://deno.land\");\nconst a2 = await globalThis.fetch(\"https://deno.land\");\nconst a3 = await self.fetch(\"https://deno.land\");\n\nconst b1 = Deno.metrics();\nconst b2 = globalThis.Deno.metrics();\nconst b3 = self.Deno.metrics();\nconsole.log(globalThis);\n\naddEventListener(\"load\", () => {\n  console.log(\"Loaded.\");\n});\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-window-prefix",
    "docs": "Disallows the use of Web APIs via the `window` object.\n\nIn most situations, the global variable `window` works like `globalThis`. For\nexample, you could call the `fetch` API like `window.fetch(..)` instead of\n`fetch(..)` or `globalThis.fetch(..)`. In Web Workers, however, `window` is not\navailable, but instead `self`, `globalThis`, or no prefix work fine. Therefore,\nfor compatibility between Web Workers and other contexts, it's highly\nrecommended to not access global properties via `window`.\n\nSome APIs, including `window.alert`, `window.location` and `window.history`, are\nallowed to call with `window` because these APIs are not supported or have\ndifferent meanings in Workers. In other words, this lint rule complains about\nthe use of `window` only if it's completely replaceable with `self`,\n`globalThis`, or no prefix.\n\n### Invalid:\n\n```typescript\nconst a = await window.fetch(\"https://deno.land\");\n\nconst b = window.Deno.metrics();\n```\n\n### Valid:\n\n```typescript\nconst a1 = await fetch(\"https://deno.land\");\nconst a2 = await globalThis.fetch(\"https://deno.land\");\nconst a3 = await self.fetch(\"https://deno.land\");\n\nconst b1 = Deno.metrics();\nconst b2 = globalThis.Deno.metrics();\nconst b3 = self.Deno.metrics();\n\n// `alert` is allowed to call with `window` because it's not supported in Workers\nwindow.alert(\"🍣\");\n\n// `location` is also allowed\nwindow.location.host;\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "no-with",
    "docs": "Disallows the usage of `with` statements.\n\nThe `with` statement is discouraged as it may be the source of confusing bugs\nand compatibility issues. For more details, see [with - JavaScript | MDN].\n\n[with - JavaScript | MDN]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/with\n\n### Invalid:\n\n```typescript\nwith (someVar) {\n  console.log(\"foo\");\n}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "prefer-as-const",
    "docs": "Recommends using const assertion (`as const`) over explicitly specifying literal\ntypes or using type assertion.\n\nWhen declaring a new variable of a primitive literal type, there are three ways:\n\n1. adding an explicit type annotation\n2. using normal type assertion (like `as \"foo\"`, or `<\"foo\">`)\n3. using const assertion (`as const`)\n\nThis lint rule suggests using const assertion because it will generally lead to\na safer code. For more details about const assertion, see\n[the official handbook](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-4.html#const-assertions).\n\n### Invalid:\n\n```typescript\nlet a: 2 = 2; // type annotation\nlet b = 2 as 2; // type assertion\nlet c = <2> 2; // type assertion\nlet d = { foo: 1 as 1 }; // type assertion\n```\n\n### Valid:\n\n```typescript\nlet a = 2 as const;\nlet b = 2 as const;\nlet c = 2 as const;\nlet d = { foo: 1 as const };\n\nlet x = 2;\nlet y: string = \"hello\";\nlet z: number = someVariable;\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "prefer-ascii",
    "docs": "Ensures that the code is fully written in ASCII characters.\n\nV8, the JavaScript engine Deno relies on, provides a method that strings get\npopulated outside V8's heap. In particular, if they are composed of one-byte\ncharacters only, V8 can handle them much more efficiently through\n[`v8::String::ExternalOneByteStringResource`]. In order to leverage this V8\nfeature in the internal of Deno, this rule checks if all characters in the code\nare ASCII.\n\n[`v8::String::ExternalOneByteStringResource`]: https://v8.github.io/api/head/classv8_1_1String_1_1ExternalOneByteStringResource.html\n\nThat said, you can also make use of this lint rule for something other than\nDeno's internal JavaScript code. If you want to make sure your codebase is made\nup of ASCII characters only (e.g. want to disallow non-ASCII identifiers) for\nsome reasons, then this rule will be helpful.\n\n### Invalid:\n\n```typescript\nconst π = Math.PI;\n\n// string literals are also checked\nconst ninja = \"🥷\";\n\nfunction こんにちは(名前: string) {\n  console.log(`こんにちは、${名前}さん`);\n}\n\n// “comments” are also checked\n// ^        ^\n// |        U+201D\n// U+201C\n```\n\n### Valid:\n\n```typescript\nconst pi = Math.PI;\n\nconst ninja = \"ninja\";\n\nfunction hello(name: string) {\n  console.log(`Hello, ${name}`);\n}\n\n// \"comments\" are also checked\n```\n",
    "tags": []
  },
  {
    "code": "prefer-const",
    "docs": "Recommends declaring variables with [`const`] over [`let`].\n\nSince ES2015, JavaScript supports [`let`] and [`const`] for declaring variables.\nIf variables are declared with [`let`], then they become mutable; we can set\nother values to them afterwards. Meanwhile, if declared with [`const`], they are\nimmutable; we cannot perform re-assignment to them.\n\nIn general, to make the codebase more robust, maintainable, and readable, it is\nhighly recommended to use [`const`] instead of [`let`] wherever possible. The\nfewer mutable variables are, the easier it should be to keep track of the\nvariable states while reading through the code, and thus it is less likely to\nwrite buggy code. So this lint rule checks if there are [`let`] variables that\ncould potentially be declared with [`const`] instead.\n\nNote that this rule does not check for [`var`] variables. Instead,\n[the `no-var` rule](https://lint.deno.land/rules/no-var) is responsible for\ndetecting and warning [`var`] variables.\n\n[`let`]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let\n[`const`]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/const\n[`var`]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/var\n\n### Invalid:\n\n```typescript\nlet a = 0;\n\nlet b = 0;\nsomeOperation(b);\n\n// `const` could be used instead\nfor (let c in someObject) {}\n\n// `const` could be used instead\nfor (let d of someArray) {}\n\n// variable that is uninitialized at first and then assigned in the same scope is NOT allowed\n// because we could simply write it like `const e = 2;` instead\nlet e;\ne = 2;\n```\n\n### Valid:\n\n```typescript\n// uninitialized variable is allowed\nlet a;\n\nlet b = 0;\nb += 1;\n\nlet c = 0;\nc = 1;\n\n// variable that is uninitialized at first and then assigned in the same scope _two or more times_ is allowed\n// because we cannot represent it with `const`\nlet d;\nd = 2;\nd = 3;\n\nconst e = 0;\n\n// `f` is mutated through `f++`\nfor (let f = 0; f < someArray.length; f++) {}\n\n// variable that is initialized (or assigned) in another scope is allowed\nlet g;\nfunction func1() {\n  g = 42;\n}\n\n// conditionally initialized variable is allowed\nlet h;\nif (trueOrFalse) {\n  h = 0;\n}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "prefer-namespace-keyword",
    "docs": "Recommends the use of `namespace` keyword over `module` keyword when declaring\nTypeScript module.\n\nTypeScript supports the `module` keyword for organizing code, but this wording\ncan lead to a confusion with the ECMAScript's module. Since TypeScript v1.5, it\nhas provided us with the alternative keyword `namespace`, encouraging us to\nalways use `namespace` instead whenever we write TypeScript these days. See\n[TypeScript v1.5 release note](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-1-5.html#namespace-keyword)\nfor more details.\n\n### Invalid:\n\n```typescript\nmodule modA {}\n\ndeclare module modB {}\n```\n\n### Valid:\n\n```typescript\nnamespace modA {}\n\n// \"ambient modules\" are allowed\n// https://www.typescriptlang.org/docs/handbook/modules.html#ambient-modules\ndeclare module \"modB\";\ndeclare module \"modC\" {}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "prefer-primordials",
    "docs": "Suggests using frozen intrinsics from `primordials` rather than the default\nglobals.\n\nThis lint rule is designed to be dedicated to Deno's internal code. Normal users\ndon't have to run this rule for their code.\n\nPrimordials are a frozen set of all intrinsic objects in the runtime, which we\nshould use in the Deno's internal to avoid the risk of prototype pollution. This\nrule detects the direct use of global intrinsics and suggests replacing it with\nthe corresponding one from the `primordials` object.\n\nOne such example is:\n\n```javascript\nconst arr = getSomeArrayOfNumbers();\nconst evens = arr.filter((val) => val % 2 === 0);\n```\n\nThe second line of this example should be:\n\n```javascript\nconst evens = primordials.ArrayPrototypeFilter(arr, (val) => val % 2 === 0);\n```\n\n### Invalid:\n\n```javascript\nconst arr = new Array();\n\nconst s = JSON.stringify({});\n\nconst i = parseInt(\"42\");\n\nconst { ownKeys } = Reflect;\n```\n\n### Valid:\n\n```javascript\nconst { Array } = primordials;\nconst arr = new Array();\n\nconst { JSONStringify } = primordials;\nconst s = JSONStringify({});\n\nconst { NumberParseInt } = primordials;\nconst i = NumberParseInt(\"42\");\n\nconst { ReflectOwnKeys } = primordials;\n```\n",
    "tags": []
  },
  {
    "code": "require-await",
    "docs": "Disallows async functions that have no await expression or await using\ndeclaration\n\nIn general, the primary reason to use async functions is to use await\nexpressions or await using declarations inside. If an async function has\nneither, it is most likely an unintentional mistake.\n\n### Invalid:\n\n```typescript\nasync function f1() {\n  doSomething();\n}\n\nconst f2 = async () => {\n  doSomething();\n};\n\nconst f3 = async () => doSomething();\n\nconst obj = {\n  async method() {\n    doSomething();\n  },\n};\n\nclass MyClass {\n  async method() {\n    doSomething();\n  }\n}\n```\n\n### Valid:\n\n```typescript\nawait asyncFunction();\n\nfunction normalFunction() {\n  doSomething();\n}\n\nasync function f1() {\n  await asyncFunction();\n}\n\nconst f2 = async () => {\n  await asyncFunction();\n};\n\nconst f3 = async () => await asyncFunction();\n\nasync function f4() {\n  for await (const num of asyncIterable) {\n    console.log(num);\n  }\n}\n\nasync function f5() {\n  using = createResource();\n}\n\n// empty functions are valid\nasync function emptyFunction() {}\nconst emptyArrowFunction = async () => {};\n\n// generators are also valid\nasync function* gen() {\n  console.log(42);\n}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "require-yield",
    "docs": "Disallows generator functions that have no `yield`.\n\nJavaScript provides generator functions expressed as `function*`, where we can\npause and later resume the function execution at the middle points. At these\npoints we use the `yield` keyword. In other words, it makes no sense at all to\ncreate generator functions that contain no `yield` keyword, since such functions\ncould be written as normal functions.\n\n### Invalid:\n\n```typescript\nfunction* f1() {\n  return \"f1\";\n}\n```\n\n### Valid:\n\n```typescript\nfunction* f1() {\n  yield \"f1\";\n}\n\n// generator function with empty body is allowed\nfunction* f2() {}\n\nfunction f3() {\n  return \"f3\";\n}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "single-var-declarator",
    "docs": "Disallows multiple variable definitions in the same declaration statement\n\n### Invalid:\n\n```typescript\nconst foo = 1, bar = \"2\";\n```\n\n### Valid:\n\n```typescript\nconst foo = 1;\nconst bar = \"2\";\n```\n",
    "tags": []
  },
  {
    "code": "triple-slash-reference",
    "docs": "Disallow certain triple slash directives in favor of ES6-style import\ndeclarations\n\nTypeScript's `///` triple-slash references are a way to indicate that types from\nanother module are available in a file. Use of triple-slash reference type\ndirectives is generally discouraged in favor of ECMAScript Module imports. This\nrule reports on the use of `/// <reference path=\"...\" />`,\n`/// <reference types=\"...\" />`, or `/// <reference lib=\"...\" />` directives.\n\n### Invalid:\n\n```typescript\n/// <reference types=\"foo\" />\nimport * as foo from \"foo\";\n```\n\n### Valid:\n\n```typescript\nimport * as foo from \"foo\";\n```\n",
    "tags": []
  },
  {
    "code": "use-isnan",
    "docs": "Disallows comparisons to `NaN`.\n\nBecause `NaN` is unique in JavaScript by not being equal to anything, including\nitself, the results of comparisons to `NaN` are confusing:\n\n- `NaN === NaN` or `NaN == NaN` evaluate to `false`\n- `NaN !== NaN` or `NaN != NaN` evaluate to `true`\n\nTherefore, this rule makes you use the `isNaN()` or `Number.isNaN()` to judge\nthe value is `NaN` or not.\n\n### Invalid:\n\n```typescript\nif (foo == NaN) {\n  // ...\n}\n\nif (foo != NaN) {\n  // ...\n}\n\nswitch (NaN) {\n  case foo:\n    // ...\n}\n\nswitch (foo) {\n  case NaN:\n    // ...\n}\n```\n\n### Valid:\n\n```typescript\nif (isNaN(foo)) {\n  // ...\n}\n\nif (!isNaN(foo)) {\n  // ...\n}\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "valid-typeof",
    "docs": "Restricts the use of the `typeof` operator to a specific set of string literals.\n\nWhen used with a value the `typeof` operator returns one of the following\nstrings:\n\n- `\"undefined\"`\n- `\"object\"`\n- `\"boolean\"`\n- `\"number\"`\n- `\"string\"`\n- `\"function\"`\n- `\"symbol\"`\n- `\"bigint\"`\n\nThis rule disallows comparison with anything other than one of these string\nliterals when using the `typeof` operator, as this likely represents a typing\nmistake in the string. The rule also disallows comparing the result of a\n`typeof` operation with any non-string literal value, such as `undefined`, which\ncan represent an inadvertent use of a keyword instead of a string. This includes\ncomparing against string variables even if they contain one of the above values\nas this cannot be guaranteed. An exception to this is comparing the results of\ntwo `typeof` operations as these are both guaranteed to return on of the above\nstrings.\n\n### Invalid:\n\n```typescript\n// typo\ntypeof foo === \"strnig\";\ntypeof foo == \"undefimed\";\ntypeof bar != \"nunber\";\ntypeof bar !== \"fucntion\";\n\n// compare with non-string literals\ntypeof foo === undefined;\ntypeof bar == Object;\ntypeof baz === anotherVariable;\ntypeof foo == 5;\n```\n\n### Valid:\n\n```typescript\ntypeof foo === \"undefined\";\ntypeof bar == \"object\";\ntypeof baz === \"string\";\ntypeof bar === typeof qux;\n```\n",
    "tags": [
      "recommended"
    ]
  },
  {
    "code": "verbatim-module-syntax",
    "docs": "Enforces type imports to be declared as type imports.\n\nThis rule ensures that the code works when the `verbatimModuleSyntax` TypeScript\ncompiler option is enabled. This is useful in libraries distributing TypeScript\ncode in order to work in more scenarios.\n\n### Invalid:\n\n```typescript\nimport { Person } from \"./person.ts\";\n\nconst person: Person = {\n  name: \"David\",\n};\nconsole.log(person);\n```\n\n```typescript\nimport { output, Person } from \"./person.ts\";\n\nconst person: Person = {\n  name: \"David\",\n};\noutput(person);\n```\n\n### Valid:\n\n```typescript\nimport type { Person } from \"./person.ts\";\n\nconst person: Person = {\n  name: \"David\",\n};\nconsole.log(person);\n```\n\n```typescript\nimport { output, type Person } from \"./person.ts\";\n\nconst person: Person = {\n  name: \"David\",\n};\noutput(person);\n```\n",
    "tags": [
      "jsr"
    ]
  }
]