From 0c095eee474c6a08c6a59bef1f07c3f0113ecf8b Mon Sep 17 00:00:00 2001 From: "oxc-guard[bot]" <276638029+oxc-guard[bot]@users.noreply.github.com> Date: Mon, 4 May 2026 09:58:02 +0000 Subject: [PATCH] Release 1.63.0 --- .vitepress/data/rules.json | 284 +++++++++++++++++- src/docs/guide/usage/linter/generated-cli.md | 2 +- .../usage/linter/generated-lsp-config.md | 93 ++++++ .../eslint/logical-assignment-operators.md | 131 ++++++++ .../rules/eslint/no-restricted-properties.md | 169 +++++++++++ .../linter/rules/jest/no-test-prefixes.md | 11 - .../rules/jest/no-test-return-statement.md | 11 - .../jest/no-unneeded-async-expect-function.md | 11 - .../linter/rules/jest/prefer-called-with.md | 11 - .../rules/jest/prefer-comparison-matcher.md | 11 - .../usage/linter/rules/jest/prefer-each.md | 11 - .../rules/jest/prefer-equality-matcher.md | 11 - .../rules/jest/prefer-expect-resolves.md | 11 - .../rules/jest/prefer-hooks-in-order.md | 11 - .../linter/rules/jest/prefer-hooks-on-top.md | 11 - .../rules/jest/prefer-lowercase-title.md | 13 +- .../jest/prefer-mock-promise-shorthand.md | 11 - .../jest/prefer-mock-return-shorthand.md | 13 +- .../linter/rules/jest/prefer-snapshot-hint.md | 11 - .../usage/linter/rules/jest/prefer-spy-on.md | 11 - .../linter/rules/jest/prefer-strict-equal.md | 11 - .../usage/linter/rules/jest/prefer-to-be.md | 11 - .../jest/prefer-to-have-been-called-times.md | 11 - .../rules/jest/prefer-to-have-length.md | 11 - .../usage/linter/rules/jest/require-hook.md | 11 - .../rules/jest/require-to-throw-message.md | 11 - .../rules/jest/valid-describe-callback.md | 11 - .../jsx_a11y/interactive-supports-focus.md | 77 +++++ .../linter/rules/oxc/branches-sharing-code.md | 2 +- .../linter/rules/typescript/no-misused-new.md | 14 +- .../rules/unicorn/no-negated-condition.md | 63 ++++ .../linter/rules/unicorn/prefer-array-some.md | 2 +- .../guide/usage/linter/rules/version.data.js | 2 +- .../linter/rules/vitest/no-test-prefixes.md | 55 ++++ .../rules/vitest/no-test-return-statement.md | 57 ++++ .../no-unneeded-async-expect-function.md | 57 ++++ .../linter/rules/vitest/prefer-called-with.md | 59 ++++ .../rules/vitest/prefer-comparison-matcher.md | 66 ++++ .../usage/linter/rules/vitest/prefer-each.md | 59 ++++ .../rules/vitest/prefer-equality-matcher.md | 60 ++++ .../rules/vitest/prefer-expect-resolves.md | 81 +++++ .../rules/vitest/prefer-hooks-in-order.md | 134 +++++++++ .../rules/vitest/prefer-hooks-on-top.md | 152 ++++++++++ .../rules/vitest/prefer-lowercase-title.md | 173 +++++++++++ .../vitest/prefer-mock-promise-shorthand.md | 69 +++++ .../vitest/prefer-mock-return-shorthand.md | 70 +++++ .../rules/vitest/prefer-snapshot-hint.md | 207 +++++++++++++ .../linter/rules/vitest/prefer-spy-on.md | 66 ++++ .../rules/vitest/prefer-strict-equal.md | 54 ++++ .../usage/linter/rules/vitest/prefer-to-be.md | 65 ++++ .../prefer-to-have-been-called-times.md | 58 ++++ .../rules/vitest/prefer-to-have-length.md | 55 ++++ .../usage/linter/rules/vitest/require-hook.md | 159 ++++++++++ .../rules/vitest/require-to-throw-message.md | 65 ++++ .../rules/vitest/valid-describe-callback.md | 66 ++++ .../vue/no-deprecated-model-definition.md | 85 ++++++ .../rules/vue/return-in-computed-property.md | 80 +++++ src/docs/guide/usage/rule-count.data.js | 2 +- 58 files changed, 2886 insertions(+), 253 deletions(-) create mode 100644 src/docs/guide/usage/linter/generated-lsp-config.md create mode 100644 src/docs/guide/usage/linter/rules/eslint/logical-assignment-operators.md create mode 100644 src/docs/guide/usage/linter/rules/eslint/no-restricted-properties.md create mode 100644 src/docs/guide/usage/linter/rules/jsx_a11y/interactive-supports-focus.md create mode 100644 src/docs/guide/usage/linter/rules/unicorn/no-negated-condition.md create mode 100644 src/docs/guide/usage/linter/rules/vitest/no-test-prefixes.md create mode 100644 src/docs/guide/usage/linter/rules/vitest/no-test-return-statement.md create mode 100644 src/docs/guide/usage/linter/rules/vitest/no-unneeded-async-expect-function.md create mode 100644 src/docs/guide/usage/linter/rules/vitest/prefer-called-with.md create mode 100644 src/docs/guide/usage/linter/rules/vitest/prefer-comparison-matcher.md create mode 100644 src/docs/guide/usage/linter/rules/vitest/prefer-each.md create mode 100644 src/docs/guide/usage/linter/rules/vitest/prefer-equality-matcher.md create mode 100644 src/docs/guide/usage/linter/rules/vitest/prefer-expect-resolves.md create mode 100644 src/docs/guide/usage/linter/rules/vitest/prefer-hooks-in-order.md create mode 100644 src/docs/guide/usage/linter/rules/vitest/prefer-hooks-on-top.md create mode 100644 src/docs/guide/usage/linter/rules/vitest/prefer-lowercase-title.md create mode 100644 src/docs/guide/usage/linter/rules/vitest/prefer-mock-promise-shorthand.md create mode 100644 src/docs/guide/usage/linter/rules/vitest/prefer-mock-return-shorthand.md create mode 100644 src/docs/guide/usage/linter/rules/vitest/prefer-snapshot-hint.md create mode 100644 src/docs/guide/usage/linter/rules/vitest/prefer-spy-on.md create mode 100644 src/docs/guide/usage/linter/rules/vitest/prefer-strict-equal.md create mode 100644 src/docs/guide/usage/linter/rules/vitest/prefer-to-be.md create mode 100644 src/docs/guide/usage/linter/rules/vitest/prefer-to-have-been-called-times.md create mode 100644 src/docs/guide/usage/linter/rules/vitest/prefer-to-have-length.md create mode 100644 src/docs/guide/usage/linter/rules/vitest/require-hook.md create mode 100644 src/docs/guide/usage/linter/rules/vitest/require-to-throw-message.md create mode 100644 src/docs/guide/usage/linter/rules/vitest/valid-describe-callback.md create mode 100644 src/docs/guide/usage/linter/rules/vue/no-deprecated-model-definition.md create mode 100644 src/docs/guide/usage/linter/rules/vue/return-in-computed-property.md diff --git a/.vitepress/data/rules.json b/.vitepress/data/rules.json index f8d1c5c4583..27889dc04db 100644 --- a/.vitepress/data/rules.json +++ b/.vitepress/data/rules.json @@ -219,6 +219,16 @@ "default": false, "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/eslint/init-declarations.html" }, + { + "scope": "eslint", + "value": "logical-assignment-operators", + "category": "style", + "version": "next", + "type_aware": false, + "fix": "pending", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/eslint/logical-assignment-operators.html" + }, { "scope": "eslint", "value": "max-classes-per-file", @@ -1069,6 +1079,16 @@ "default": false, "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/eslint/no-restricted-imports.html" }, + { + "scope": "eslint", + "value": "no-restricted-properties", + "category": "restriction", + "version": "next", + "type_aware": false, + "fix": "none", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/eslint/no-restricted-properties.html" + }, { "scope": "eslint", "value": "no-return-assign", @@ -2999,6 +3019,16 @@ "default": false, "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/jsx_a11y/img-redundant-alt.html" }, + { + "scope": "jsx_a11y", + "value": "interactive-supports-focus", + "category": "correctness", + "version": "next", + "type_aware": false, + "fix": "fixable_suggestion", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/jsx_a11y/interactive-supports-focus.html" + }, { "scope": "jsx_a11y", "value": "label-has-associated-control", @@ -3515,7 +3545,7 @@ "category": "pedantic", "version": "1.22.0", "type_aware": false, - "fix": "none", + "fix": "fixable_suggestion", "default": false, "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/oxc/branches-sharing-code.html" }, @@ -5939,6 +5969,16 @@ "default": false, "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/unicorn/no-magic-array-flat-depth.html" }, + { + "scope": "unicorn", + "value": "no-negated-condition", + "category": "pedantic", + "version": "0.0.18", + "type_aware": false, + "fix": "pending", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/unicorn/no-negated-condition.html" + }, { "scope": "unicorn", "value": "no-negation-in-equality-check", @@ -6295,7 +6335,7 @@ "category": "pedantic", "version": "0.0.18", "type_aware": false, - "fix": "fixable_fix", + "fix": "fixable_suggestion", "default": false, "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/unicorn/prefer-array-some.html" }, @@ -7119,6 +7159,36 @@ "default": false, "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/no-standalone-expect.html" }, + { + "scope": "vitest", + "value": "no-test-prefixes", + "category": "style", + "version": "0.0.7", + "type_aware": false, + "fix": "fixable_fix", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/no-test-prefixes.html" + }, + { + "scope": "vitest", + "value": "no-test-return-statement", + "category": "style", + "version": "0.2.0", + "type_aware": false, + "fix": "none", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/no-test-return-statement.html" + }, + { + "scope": "vitest", + "value": "no-unneeded-async-expect-function", + "category": "style", + "version": "1.39.0", + "type_aware": false, + "fix": "fixable_fix", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/no-unneeded-async-expect-function.html" + }, { "scope": "vitest", "value": "prefer-called-exactly-once-with", @@ -7149,6 +7219,26 @@ "default": false, "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/prefer-called-times.html" }, + { + "scope": "vitest", + "value": "prefer-called-with", + "category": "style", + "version": "0.2.5", + "type_aware": false, + "fix": "fixable_fix", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/prefer-called-with.html" + }, + { + "scope": "vitest", + "value": "prefer-comparison-matcher", + "category": "style", + "version": "0.2.15", + "type_aware": false, + "fix": "fixable_fix", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/prefer-comparison-matcher.html" + }, { "scope": "vitest", "value": "prefer-describe-function-title", @@ -7159,6 +7249,26 @@ "default": false, "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/prefer-describe-function-title.html" }, + { + "scope": "vitest", + "value": "prefer-each", + "category": "style", + "version": "0.9.0", + "type_aware": false, + "fix": "none", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/prefer-each.html" + }, + { + "scope": "vitest", + "value": "prefer-equality-matcher", + "category": "style", + "version": "0.2.9", + "type_aware": false, + "fix": "fixable_suggestion", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/prefer-equality-matcher.html" + }, { "scope": "vitest", "value": "prefer-expect-assertions", @@ -7169,6 +7279,16 @@ "default": false, "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/prefer-expect-assertions.html" }, + { + "scope": "vitest", + "value": "prefer-expect-resolves", + "category": "style", + "version": "0.2.14", + "type_aware": false, + "fix": "fixable_fix", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/prefer-expect-resolves.html" + }, { "scope": "vitest", "value": "prefer-expect-type-of", @@ -7179,6 +7299,26 @@ "default": false, "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/prefer-expect-type-of.html" }, + { + "scope": "vitest", + "value": "prefer-hooks-in-order", + "category": "style", + "version": "0.6.0", + "type_aware": false, + "fix": "none", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/prefer-hooks-in-order.html" + }, + { + "scope": "vitest", + "value": "prefer-hooks-on-top", + "category": "style", + "version": "0.4.2", + "type_aware": false, + "fix": "none", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/prefer-hooks-on-top.html" + }, { "scope": "vitest", "value": "prefer-import-in-mock", @@ -7199,6 +7339,56 @@ "default": false, "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/prefer-importing-vitest-globals.html" }, + { + "scope": "vitest", + "value": "prefer-lowercase-title", + "category": "style", + "version": "0.15.9", + "type_aware": false, + "fix": "fixable_fix", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/prefer-lowercase-title.html" + }, + { + "scope": "vitest", + "value": "prefer-mock-promise-shorthand", + "category": "style", + "version": "0.2.16", + "type_aware": false, + "fix": "conditional_fix", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/prefer-mock-promise-shorthand.html" + }, + { + "scope": "vitest", + "value": "prefer-mock-return-shorthand", + "category": "style", + "version": "1.49.0", + "type_aware": false, + "fix": "fixable_fix", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/prefer-mock-return-shorthand.html" + }, + { + "scope": "vitest", + "value": "prefer-snapshot-hint", + "category": "correctness", + "version": "1.59.0", + "type_aware": false, + "fix": "none", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/prefer-snapshot-hint.html" + }, + { + "scope": "vitest", + "value": "prefer-spy-on", + "category": "style", + "version": "0.2.14", + "type_aware": false, + "fix": "fixable_suggestion", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/prefer-spy-on.html" + }, { "scope": "vitest", "value": "prefer-strict-boolean-matchers", @@ -7209,6 +7399,26 @@ "default": false, "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/prefer-strict-boolean-matchers.html" }, + { + "scope": "vitest", + "value": "prefer-strict-equal", + "category": "style", + "version": "0.2.13", + "type_aware": false, + "fix": "fixable_fix", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/prefer-strict-equal.html" + }, + { + "scope": "vitest", + "value": "prefer-to-be", + "category": "style", + "version": "0.2.14", + "type_aware": false, + "fix": "fixable_fix", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/prefer-to-be.html" + }, { "scope": "vitest", "value": "prefer-to-be-falsy", @@ -7249,6 +7459,26 @@ "default": false, "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/prefer-to-contain.html" }, + { + "scope": "vitest", + "value": "prefer-to-have-been-called-times", + "category": "style", + "version": "1.34.0", + "type_aware": false, + "fix": "fixable_fix", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/prefer-to-have-been-called-times.html" + }, + { + "scope": "vitest", + "value": "prefer-to-have-length", + "category": "style", + "version": "0.2.13", + "type_aware": false, + "fix": "fixable_fix", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/prefer-to-have-length.html" + }, { "scope": "vitest", "value": "prefer-todo", @@ -7269,6 +7499,16 @@ "default": false, "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/require-awaited-expect-poll.html" }, + { + "scope": "vitest", + "value": "require-hook", + "category": "style", + "version": "0.3.2", + "type_aware": false, + "fix": "none", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/require-hook.html" + }, { "scope": "vitest", "value": "require-local-test-context-for-concurrent-snapshots", @@ -7299,6 +7539,16 @@ "default": false, "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/require-test-timeout.html" }, + { + "scope": "vitest", + "value": "require-to-throw-message", + "category": "correctness", + "version": "0.2.9", + "type_aware": false, + "fix": "none", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/require-to-throw-message.html" + }, { "scope": "vitest", "value": "require-top-level-describe", @@ -7309,6 +7559,16 @@ "default": false, "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/require-top-level-describe.html" }, + { + "scope": "vitest", + "value": "valid-describe-callback", + "category": "correctness", + "version": "0.0.8", + "type_aware": false, + "fix": "none", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vitest/valid-describe-callback.html" + }, { "scope": "vitest", "value": "valid-expect", @@ -7439,6 +7699,16 @@ "default": false, "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vue/no-deprecated-events-api.html" }, + { + "scope": "vue", + "value": "no-deprecated-model-definition", + "category": "correctness", + "version": "next", + "type_aware": false, + "fix": "pending", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vue/no-deprecated-model-definition.html" + }, { "scope": "vue", "value": "no-deprecated-vue-config-keycodes", @@ -7539,6 +7809,16 @@ "default": false, "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vue/require-typed-ref.html" }, + { + "scope": "vue", + "value": "return-in-computed-property", + "category": "correctness", + "version": "next", + "type_aware": false, + "fix": "none", + "default": false, + "docs_url": "https://oxc.rs/docs/guide/usage/linter/rules/vue/return-in-computed-property.html" + }, { "scope": "vue", "value": "valid-define-emits", diff --git a/src/docs/guide/usage/linter/generated-cli.md b/src/docs/guide/usage/linter/generated-cli.md index 1dc1ca72c51..dd786144a72 100644 --- a/src/docs/guide/usage/linter/generated-cli.md +++ b/src/docs/guide/usage/linter/generated-cli.md @@ -115,7 +115,7 @@ Arguments: ## Output - **`-f`**, **`--format`**=_`ARG`_ — - Use a specific output format. Possible values: `checkstyle`, `default`, `github`, `gitlab`, `json`, `junit`, `stylish`, `unix` + Use a specific output format. Possible values: `checkstyle`, `default`, `github`, `gitlab`, `json`, `junit`, `sarif`, `stylish`, `unix` ## Miscellaneous diff --git a/src/docs/guide/usage/linter/generated-lsp-config.md b/src/docs/guide/usage/linter/generated-lsp-config.md new file mode 100644 index 00000000000..a8b9cc0b4c1 --- /dev/null +++ b/src/docs/guide/usage/linter/generated-lsp-config.md @@ -0,0 +1,93 @@ +--- +search: false +--- + +# LSP Options for linting, which can be defined for each workspace folder separately. + +It can be sent by the client in `initialize` or `workspace/didChangeConfiguration` requests. +If the client supports `workspace/configuration`, the server will request the options from the client. + +## Example + +Example of `initialize` request: + +```json +{ + "processId": 123, + "rootUri": null, + "workspaceFolders": [], + "capabilities": {}, + "initializationOptions": [ + { + "workspaceUri": "file:///home/user/project", + "options": { + "unusedDisableDirectives": "deny", + "typeAware": true + } + } + ] +} +``` + +Example of `workspace/didChangeConfiguration` request: + +```json +{ + "settings": [ + { + "workspaceUri": "file:///home/user/project", + "options": { + "unusedDisableDirectives": "deny", + "disableNestedConfig": true + } + } + ] +} +``` + +## configPath + +type: `string` + +Path to the config file. Similar to `--config` CLI option. +If set, it disables searching for config files. + +## disableNestedConfig + +type: `boolean` + +Whether to disable nested config support. Similar to `--disable-nested-config` CLI option. +It gets automatically enabled when `configPath` is set. + +## fixKind + +type: `"safe_fix" | "safe_fix_or_suggestion" | "dangerous_fix" | "dangerous_fix_or_suggestion" | "none" | "all"` + +What kind of fixes to generate for code actions. + +## run + +type: `"onSave" | "onType"` + +If your editor does not support `textDocument/diagnostic`, +this option handles when diagnostics are sent to the client. + +## tsConfigPath + +type: `string` + +Path to the tsconfig file. Similar to `--tsconfig` CLI option. +If set, it disables auto discovery for tsconfig files. + +## typeAware + +type: `boolean` + +Whether to enable/disable type-aware linting. +It will override the root config's `typeAware` option if set. + +## unusedDisableDirectives + +type: `"allow" | "warn" | "deny"` + +How to handle unused disable directives. By default, they are allowed and ignored. diff --git a/src/docs/guide/usage/linter/rules/eslint/logical-assignment-operators.md b/src/docs/guide/usage/linter/rules/eslint/logical-assignment-operators.md new file mode 100644 index 00000000000..833fd6e87ad --- /dev/null +++ b/src/docs/guide/usage/linter/rules/eslint/logical-assignment-operators.md @@ -0,0 +1,131 @@ +--- +title: "eslint/logical-assignment-operators" +category: "Style" +version: "next" +default: false +type_aware: false +fix: "pending" +--- + + + + + + + +### What it does + +This rule requires or disallows logical assignment operator shorthand. + +### Why is this bad? + +ES2021 introduces the assignment operator shorthand for the logical operators `||`, `&&` and `??`. +Before, this was only allowed for mathematical operations such as `+` or `*` (see the rule `operator-assignment`). +The shorthand can be used if the assignment target and the left expression of a logical expression are the same. +For example `a = a || b` can be shortened to `a ||= b`. + +### Examples + +Examples of **incorrect** code for this rule with the default `always` option: + +```js +a = a || b; +a = a && b; +a = a ?? b; +a || (a = b); +a && (a = b); +a ?? (a = b); +a = a || b || c; +a = a && b && c; +a = a ?? b ?? c; +``` + +Examples of **correct** code for this rule with the default `always` option: + +```js +a = b; +a += b; +a ||= b; +a = b || c; +a || (b = c); +if (a) a = b; +a = a || b || c; +``` + +Examples of **incorrect** code for this rule with the `never` option: + +```js +a ||= b; +a &&= b; +a ??= b; +``` + +Examples of **correct** code for this rule with the `never` option: + +```js +a = a || b; +a = a && b; +a = a ?? b; +``` + +## Configuration + +### The 1st option + +type: `"always" | "never"` + +#### `"always"` + +This option checks for expressions that can be shortened using logical assignment operator. +For example, `a = a || b` can be shortened to `a ||= b`. +Expressions with associativity such as `a = a || b || c` are reported as being able to be shortened to `a ||= b || c` unless the evaluation order is explicitly defined using parentheses, such as `a = (a || b) || c`. + +#### `"never"` + +This option disallows logical assignment operator shorthand. +For example, `a ||= b` should be written as `a = a || b`. + +### The 2nd option + +This option is an object with the following properties: + +#### enforceForIfStatements + +type: `boolean` + +default: `false` + +This option checks for additional patterns with if statements which could be expressed with the logical assignment operator. +Only available if string option is set to `always`. + +Examples of **incorrect** code for this rule with the `["always", { enforceForIfStatements: true }]` option: + +```js +if (a) a = b; // <=> a &&= b +if (!a) a = b; // <=> a ||= b + +if (a == null) a = b; // <=> a ??= b +if (a === null || a === undefined) a = b; // <=> a ??= b +``` + +Examples of **correct** code for this rule with the `["always", { enforceForIfStatements: true }]` option: + +```js +if (a) b = c; +if (a === 0) a = b; +``` + +## How to use + + + +## Version + +This rule was added in vnext. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/eslint/no-restricted-properties.md b/src/docs/guide/usage/linter/rules/eslint/no-restricted-properties.md new file mode 100644 index 00000000000..d2425f67eff --- /dev/null +++ b/src/docs/guide/usage/linter/rules/eslint/no-restricted-properties.md @@ -0,0 +1,169 @@ +--- +title: "eslint/no-restricted-properties" +category: "Restriction" +version: "next" +default: false +type_aware: false +fix: "none" +--- + + + + + + + +### What it does + +This rule allows you to disallow access to certain properties on certain objects. + +### Why is this bad? + +Certain properties on objects may be disallowed in a codebase. This is useful for +deprecating an API or restricting usage of a module’s methods. For example, you may want +to disallow using describe.only when using Mocha or telling people to use Object.assign +instead of \_.extend. + +If you want to disallow APIs marked with `@deprecated`, consider using the type-aware +`typescript/no-deprecated` rule instead. + +### Examples + +**With options:** + +```json +"no-restricted-properties": ["error", { + "object": "JSON", + "property": "parse" +}] +``` + +Examples of **incorrect** code for this rule: + +```js +/* no-restricted-properties: ["error", { "object": "JSON", "property": "parse" }] */ + +JSON.parse('{ "json": "here" }'); // 'JSON.parse' is restricted from being used. +``` + +Examples of **correct** code for this rule: + +```js +/* no-restricted-properties: ["error", { "object": "JSON", "property": "parse" }] */ + +JSON.stringify({ json: "here" }); +``` + +**With options:** + +```json +"no-restricted-properties": ["error", { + "property": "extend", + "allowObjects": ["safeUtils"] +}] +``` + +Examples of **incorrect** code for this rule: + +```js +/* no-restricted-properties: ["error", { "property": "extend", "allowObjects": ["safeUtils"] }] */ + +unsafeUtils.extend(value); // 'extend' is restricted from being used. Property 'extend' is only allowed on these objects: safeUtils. +``` + +Examples of **correct** code for this rule: + +```js +/* no-restricted-properties: ["error", { "property": "extend", "allowObjects": ["safeUtils"] }] */ + +safeUtils.extend(value); +``` + +**With options:** + +```json +"no-restricted-properties": ["error", { + "object": "legacyApi", + "allowProperties": ["stableMethod"] +}] +``` + +Examples of **incorrect** code for this rule: + +```js +/* no-restricted-properties: ["error", { "object": "legacyApi", "allowProperties": ["stableMethod"] }] */ + +legacyApi.unstableMethod(); // 'legacyApi' is restricted from being used. Only these properties are allowed: stableMethod. +``` + +Examples of **correct** code for this rule: + +```js +/* no-restricted-properties: ["error", { "object": "legacyApi", "allowProperties": ["stableMethod"] }] */ + +legacyApi.stableMethod(); +``` + +## Configuration + +### + +type: `object` + +#### allowObjects + +type: `string[]` + +default: `null` + +Objects where property access should be allowed. This must be used with `property` and +cannot be used with `object`. + +#### allowProperties + +type: `string[]` + +default: `null` + +Properties where property access should be allowed. This must be used with `object` and +cannot be used with `property`. + +#### message + +type: `string` + +default: `null` + +A custom message to display. + +#### object + +type: `string` + +default: `null` + +The object on which the property is being accessed. + +#### property + +type: `string` + +default: `null` + +The property being accessed. If `object` is not specified, this applies to the named +property on all objects. + +## How to use + + + +## Version + +This rule was added in vnext. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/jest/no-test-prefixes.md b/src/docs/guide/usage/linter/rules/jest/no-test-prefixes.md index 4a728373558..728aa32ec00 100644 --- a/src/docs/guide/usage/linter/rules/jest/no-test-prefixes.md +++ b/src/docs/guide/usage/linter/rules/jest/no-test-prefixes.md @@ -42,17 +42,6 @@ xtest("foo"); // invalid xdescribe("foo"); // invalid ``` -This rule is compatible with [eslint-plugin-vitest](https://github.com/vitest-dev/eslint-plugin-vitest/blob/v1.1.9/docs/rules/no-test-prefixes.md), -to use it, add the following configuration to your `.oxlintrc.json`: - -```json -{ - "rules": { - "vitest/no-test-prefixes": "error" - } -} -``` - ## How to use diff --git a/src/docs/guide/usage/linter/rules/jest/no-test-return-statement.md b/src/docs/guide/usage/linter/rules/jest/no-test-return-statement.md index 89bd2c56959..c129b1c1d61 100644 --- a/src/docs/guide/usage/linter/rules/jest/no-test-return-statement.md +++ b/src/docs/guide/usage/linter/rules/jest/no-test-return-statement.md @@ -44,17 +44,6 @@ test("one", () => { }); ``` -This rule is compatible with [eslint-plugin-vitest](https://github.com/vitest-dev/eslint-plugin-vitest/blob/main/docs/rules/no-test-return-statement.md), -to use it, add the following configuration to your `.oxlintrc.json`: - -```json -{ - "rules": { - "vitest/no-test-return-statement": "error" - } -} -``` - ## How to use diff --git a/src/docs/guide/usage/linter/rules/jest/no-unneeded-async-expect-function.md b/src/docs/guide/usage/linter/rules/jest/no-unneeded-async-expect-function.md index 0f5ed3a161a..3684c50963e 100644 --- a/src/docs/guide/usage/linter/rules/jest/no-unneeded-async-expect-function.md +++ b/src/docs/guide/usage/linter/rules/jest/no-unneeded-async-expect-function.md @@ -44,17 +44,6 @@ Examples of **correct** code for this rule: await expect(doSomethingAsync()).rejects.toThrow(); ``` -This rule is compatible with [eslint-plugin-vitest](https://github.com/vitest-dev/eslint-plugin-vitest/blob/main/docs/rules/no-unneeded-async-expect-function.md), -to use it, add the following configuration to your `.oxlintrc.json`: - -```json -{ - "rules": { - "vitest/no-unneeded-async-expect-function": "error" - } -} -``` - ## How to use diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-called-with.md b/src/docs/guide/usage/linter/rules/jest/prefer-called-with.md index 9271b77c19a..62b88058b78 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-called-with.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-called-with.md @@ -46,17 +46,6 @@ expect(anyArgsFunction).toBeCalledTimes(1); expect(uncalledFunction).not.toBeCalled(); ``` -This rule is compatible with [eslint-plugin-vitest](https://github.com/vitest-dev/eslint-plugin-vitest/blob/main/docs/rules/prefer-called-with.md), -to use it, add the following configuration to your `.oxlintrc.json`: - -```json -{ - "rules": { - "vitest/prefer-called-with": "error" - } -} -``` - ## How to use diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-comparison-matcher.md b/src/docs/guide/usage/linter/rules/jest/prefer-comparison-matcher.md index 37d242c3106..451dccf4748 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-comparison-matcher.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-comparison-matcher.md @@ -53,17 +53,6 @@ expect(x).toBeLessThanOrEqual(y); expect(x < "Carl").toBe(true); ``` -This rule is compatible with [eslint-plugin-vitest](https://github.com/vitest-dev/eslint-plugin-vitest/blob/main/docs/rules/prefer-comparison-matcher.md), -to use it, add the following configuration to your `.oxlintrc.json`: - -```json -{ - "rules": { - "vitest/prefer-comparison-matcher": "error" - } -} -``` - ## How to use diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-each.md b/src/docs/guide/usage/linter/rules/jest/prefer-each.md index 23dcaf02b4a..4b012a45e63 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-each.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-each.md @@ -46,17 +46,6 @@ describe.each(items)("item", (item) => { }); ``` -This rule is compatible with [eslint-plugin-vitest](https://github.com/vitest-dev/eslint-plugin-vitest/blob/main/docs/rules/prefer-each.md), -to use it, add the following configuration to your `.oxlintrc.json`: - -```json -{ - "rules": { - "vitest/prefer-each": "error" - } -} -``` - ## How to use diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-equality-matcher.md b/src/docs/guide/usage/linter/rules/jest/prefer-equality-matcher.md index bd00b092364..88c7e8dbff1 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-equality-matcher.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-equality-matcher.md @@ -47,17 +47,6 @@ expect(name).not.toEqual("Carl"); expect(myObj).toStrictEqual(thatObj); ``` -This rule is compatible with [eslint-plugin-vitest](https://github.com/vitest-dev/eslint-plugin-vitest/blob/main/docs/rules/prefer-equality-matcher.md), -to use it, add the following configuration to your `.oxlintrc.json`: - -```json -{ - "rules": { - "vitest/prefer-equality-matcher": "error" - } -} -``` - ## How to use diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-expect-resolves.md b/src/docs/guide/usage/linter/rules/jest/prefer-expect-resolves.md index 30aac10fc1d..cede2d6f13b 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-expect-resolves.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-expect-resolves.md @@ -68,17 +68,6 @@ it("errors", async () => { }); ``` -This rule is compatible with [eslint-plugin-vitest](https://github.com/vitest-dev/eslint-plugin-vitest/blob/main/docs/rules/prefer-expect-resolves.md), -to use it, add the following configuration to your `.oxlintrc.json`: - -```json -{ - "rules": { - "vitest/prefer-expect-resolves": "error" - } -} -``` - ## How to use diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-hooks-in-order.md b/src/docs/guide/usage/linter/rules/jest/prefer-hooks-in-order.md index a426c85a3c6..507c6562c2c 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-hooks-in-order.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-hooks-in-order.md @@ -121,17 +121,6 @@ describe("foo", () => { }); ``` -This rule is compatible with [eslint-plugin-vitest](https://github.com/vitest-dev/eslint-plugin-vitest/blob/v1.1.9/docs/rules/prefer-hooks-in-order.md), -to use it, add the following configuration to your `.oxlintrc.json`: - -```json -{ - "rules": { - "vitest/prefer-hooks-in-order": "error" - } -} -``` - ## How to use diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-hooks-on-top.md b/src/docs/guide/usage/linter/rules/jest/prefer-hooks-on-top.md index d02a8a0dbb3..02f03692e09 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-hooks-on-top.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-hooks-on-top.md @@ -139,17 +139,6 @@ describe("foo", () => { }); ``` -This rule is compatible with [eslint-plugin-vitest](https://github.com/vitest-dev/eslint-plugin-vitest/blob/main/docs/rules/prefer-hooks-on-top.md), -to use it, add the following configuration to your `.oxlintrc.json`: - -```json -{ - "rules": { - "vitest/prefer-hooks-on-top": "error" - } -} -``` - ## How to use diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-lowercase-title.md b/src/docs/guide/usage/linter/rules/jest/prefer-lowercase-title.md index d3af4c10285..a8f756e7010 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-lowercase-title.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-lowercase-title.md @@ -11,7 +11,7 @@ fix: "fixable_fix" @@ -44,17 +44,6 @@ it("adds 1 + 2 to equal 3", () => { }); ``` -This rule is compatible with [eslint-plugin-vitest](https://github.com/vitest-dev/eslint-plugin-vitest/blob/main/docs/rules/prefer-lowercase-title.md), -to use it, add the following configuration to your `.oxlintrc.json`: - -```json -{ - "rules": { - "vitest/prefer-lowercase-title": "error" - } -} -``` - ## Configuration This rule accepts a configuration object with the following properties: diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-mock-promise-shorthand.md b/src/docs/guide/usage/linter/rules/jest/prefer-mock-promise-shorthand.md index f86a6e1e4d5..25ecea6baf0 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-mock-promise-shorthand.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-mock-promise-shorthand.md @@ -56,17 +56,6 @@ myFunction .mockRejectedValue(new Error("too many calls!")); ``` -This rule is compatible with [eslint-plugin-vitest](https://github.com/vitest-dev/eslint-plugin-vitest/blob/main/docs/rules/prefer-mock-promise-shorthand.md), -to use it, add the following configuration to your `.oxlintrc.json`: - -```json -{ - "rules": { - "vitest/prefer-mock-promise-shorthand": "error" - } -} -``` - ## How to use diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-mock-return-shorthand.md b/src/docs/guide/usage/linter/rules/jest/prefer-mock-return-shorthand.md index 84c0d309c2e..e373b729fb2 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-mock-return-shorthand.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-mock-return-shorthand.md @@ -22,7 +22,7 @@ When working with mocks of functions that return simple values, Jest provides so ### Why is this bad? -Not using Jest’s API sugar functions adds unnecessary boilerplate and makes tests harder to read. These helpers clearly express intent +Not using Jest's API sugar functions adds unnecessary boilerplate and makes tests harder to read. These helpers clearly express intent and reduce errors, keeping tests simple and maintainable. ### Examples @@ -57,17 +57,6 @@ jest.spyOn(fs, "readFileSync").mockImplementationOnce(() => { myFunction.mockResolvedValueOnce(42).mockResolvedValueOnce(42).mockReturnValue(0); ``` -This rule is compatible with [eslint-plugin-vitest](https://github.com/vitest-dev/eslint-plugin-vitest/blob/main/docs/rules/prefer-mock-return-shorthand.md), -to use it, add the following configuration to your `.oxlintrc.json`: - -```json -{ - "rules": { - "vitest/prefer-mock-return-shorthand": "error" - } -} -``` - ## How to use diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-snapshot-hint.md b/src/docs/guide/usage/linter/rules/jest/prefer-snapshot-hint.md index b052f2b9460..4fb2a0e5a11 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-snapshot-hint.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-snapshot-hint.md @@ -182,17 +182,6 @@ describe("cli", () => { }); ``` -This rule is compatible with [eslint-plugin-vitest](https://github.com/vitest-dev/eslint-plugin-vitest/blob/main/docs/rules/prefer-snapshot-hint.md), -to use it, add the following configuration to your `.oxlintrc.json`: - -```json -{ - "rules": { - "vitest/prefer-snapshot-hint": "error" - } -} -``` - ## Configuration This rule accepts one of the following string values: diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-spy-on.md b/src/docs/guide/usage/linter/rules/jest/prefer-spy-on.md index d8fe1605100..f5cab84a443 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-spy-on.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-spy-on.md @@ -53,17 +53,6 @@ jest.spyOn(Date, "now"); jest.spyOn(Date, "now").mockImplementation(() => 10); ``` -This rule is compatible with [eslint-plugin-vitest](https://github.com/vitest-dev/eslint-plugin-vitest/blob/main/docs/rules/prefer-spy-on.md), -to use it, add the following configuration to your `.oxlintrc.json`: - -```json -{ - "rules": { - "vitest/prefer-spy-on": "error" - } -} -``` - ## How to use diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-strict-equal.md b/src/docs/guide/usage/linter/rules/jest/prefer-strict-equal.md index ae9e59c9e94..9a8166b94a5 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-strict-equal.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-strict-equal.md @@ -41,17 +41,6 @@ Examples of **correct** code for this rule: expect({ a: "a", b: undefined }).toStrictEqual({ a: "a" }); ``` -This rule is compatible with [eslint-plugin-vitest](https://github.com/vitest-dev/eslint-plugin-vitest/blob/main/docs/rules/prefer-strict-equal.md), -to use it, add the following configuration to your `.oxlintrc.json`: - -```json -{ - "rules": { - "vitest/prefer-strict-equal": "error" - } -} -``` - ## How to use diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-to-be.md b/src/docs/guide/usage/linter/rules/jest/prefer-to-be.md index b875ff95c0a..5fd4082e3d1 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-to-be.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-to-be.md @@ -52,17 +52,6 @@ expect(didError).not.toBe(true); expect(catchError()).toStrictEqual({ message: "oh noes!" }); ``` -This rule is compatible with [eslint-plugin-vitest](https://github.com/vitest-dev/eslint-plugin-vitest/blob/main/docs/rules/prefer-to-be.md), -to use it, add the following configuration to your `.oxlintrc.json`: - -```json -{ - "rules": { - "vitest/prefer-to-be": "error" - } -} -``` - ## How to use diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-to-have-been-called-times.md b/src/docs/guide/usage/linter/rules/jest/prefer-to-have-been-called-times.md index 346027f1dcb..c22c3c40466 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-to-have-been-called-times.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-to-have-been-called-times.md @@ -45,17 +45,6 @@ expect(uncalledFunction).not.toBeCalled(); expect(method.mock.calls[0][0]).toStrictEqual(value); ``` -This rule is compatible with [eslint-plugin-vitest](https://github.com/vitest-dev/eslint-plugin-vitest/blob/main/docs/rules/prefer-to-have-been-called-times.md), -to use it, add the following configuration to your `.oxlintrc.json`: - -```json -{ - "rules": { - "vitest/prefer-to-have-been-called-times": "error" - } -} -``` - ## How to use diff --git a/src/docs/guide/usage/linter/rules/jest/prefer-to-have-length.md b/src/docs/guide/usage/linter/rules/jest/prefer-to-have-length.md index 99293edb3e1..3c223455c0d 100644 --- a/src/docs/guide/usage/linter/rules/jest/prefer-to-have-length.md +++ b/src/docs/guide/usage/linter/rules/jest/prefer-to-have-length.md @@ -42,17 +42,6 @@ Examples of **correct** code for this rule: expect(files).toHaveLength(1); ``` -This rule is compatible with [eslint-plugin-vitest](https://github.com/vitest-dev/eslint-plugin-vitest/blob/main/docs/rules/prefer-to-have-length.md), -to use it, add the following configuration to your `.oxlintrc.json`: - -```json -{ - "rules": { - "vitest/prefer-to-have-length": "error" - } -} -``` - ## How to use diff --git a/src/docs/guide/usage/linter/rules/jest/require-hook.md b/src/docs/guide/usage/linter/rules/jest/require-hook.md index 1131efbac3a..545e72226d5 100644 --- a/src/docs/guide/usage/linter/rules/jest/require-hook.md +++ b/src/docs/guide/usage/linter/rules/jest/require-hook.md @@ -134,17 +134,6 @@ afterEach(() => { }); ``` -This rule is compatible with [eslint-plugin-vitest](https://github.com/vitest-dev/eslint-plugin-vitest/blob/main/docs/rules/require-hook.md), -to use it, add the following configuration to your `.oxlintrc.json`: - -```json -{ - "rules": { - "vitest/require-hook": "error" - } -} -``` - ## Configuration This rule accepts a configuration object with the following properties: diff --git a/src/docs/guide/usage/linter/rules/jest/require-to-throw-message.md b/src/docs/guide/usage/linter/rules/jest/require-to-throw-message.md index d8a563fdd3c..5d8b03e7c90 100644 --- a/src/docs/guide/usage/linter/rules/jest/require-to-throw-message.md +++ b/src/docs/guide/usage/linter/rules/jest/require-to-throw-message.md @@ -52,17 +52,6 @@ test("all the things", async () => { }); ``` -This rule is compatible with [eslint-plugin-vitest](https://github.com/vitest-dev/eslint-plugin-vitest/blob/main/docs/rules/require-to-throw-message.md), -to use it, add the following configuration to your `.oxlintrc.json`: - -```json -{ - "rules": { - "vitest/require-to-throw-message": "error" - } -} -``` - ## How to use diff --git a/src/docs/guide/usage/linter/rules/jest/valid-describe-callback.md b/src/docs/guide/usage/linter/rules/jest/valid-describe-callback.md index 5fca5cadff8..825e48c40fb 100644 --- a/src/docs/guide/usage/linter/rules/jest/valid-describe-callback.md +++ b/src/docs/guide/usage/linter/rules/jest/valid-describe-callback.md @@ -53,17 +53,6 @@ describe("myFunction", () => })); ``` -This rule is compatible with [eslint-plugin-vitest](https://github.com/vitest-dev/eslint-plugin-vitest/blob/v1.1.9/docs/rules/valid-describe-callback.md), -to use it, add the following configuration to your `.oxlintrc.json`: - -```json -{ - "rules": { - "vitest/valid-describe-callback": "error" - } -} -``` - ## How to use diff --git a/src/docs/guide/usage/linter/rules/jsx_a11y/interactive-supports-focus.md b/src/docs/guide/usage/linter/rules/jsx_a11y/interactive-supports-focus.md new file mode 100644 index 00000000000..f86a337c099 --- /dev/null +++ b/src/docs/guide/usage/linter/rules/jsx_a11y/interactive-supports-focus.md @@ -0,0 +1,77 @@ +--- +title: "jsx-a11y/interactive-supports-focus" +category: "Correctness" +version: "next" +default: false +type_aware: false +fix: "fixable_suggestion" +--- + + + + + + + +### What it does + +Enforce that elements with interactive roles and interaction handlers +(mouse or key press) must be focusable. + +### Why is this bad? + +Elements that handle user interaction (e.g., `onClick`) but are not +natively focusable (like `
` or ``) must be made focusable so +that keyboard-only users and assistive technology users can reach and +activate them. + +Without a `tabIndex`, these elements are unreachable via keyboard navigation, +creating a barrier for users who cannot use a mouse. + +### Examples + +Examples of **incorrect** code for this rule: + +```jsx +Submit +Next page +``` + +Examples of **correct** code for this rule: + +```jsx +
void 0} /> +Click me! +Click me too! +Click ALL the things! + +``` + +## Configuration + +This rule accepts a configuration object with the following properties: + +### tabbable + +type: `string[]` + +default: `["button", "checkbox", "link", "searchbox", "spinbutton", "switch", "textbox"]` + +An array of interactive ARIA roles that should be considered tabbable (require `tabIndex={0}`). +Interactive roles not in this list are only required to be focusable (`tabIndex={-1}` is sufficient). +Defaults to `["button", "checkbox", "link", "searchbox", "spinbutton", "switch", "textbox"]`. + +## How to use + + + +## Version + +This rule was added in vnext. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/oxc/branches-sharing-code.md b/src/docs/guide/usage/linter/rules/oxc/branches-sharing-code.md index b2317bc8e6d..47e7e4b5571 100644 --- a/src/docs/guide/usage/linter/rules/oxc/branches-sharing-code.md +++ b/src/docs/guide/usage/linter/rules/oxc/branches-sharing-code.md @@ -4,7 +4,7 @@ category: "Pedantic" version: "1.22.0" default: false type_aware: false -fix: "none" +fix: "fixable_suggestion" --- diff --git a/src/docs/guide/usage/linter/rules/typescript/no-misused-new.md b/src/docs/guide/usage/linter/rules/typescript/no-misused-new.md index be9244cbaf0..bd054937ecd 100644 --- a/src/docs/guide/usage/linter/rules/typescript/no-misused-new.md +++ b/src/docs/guide/usage/linter/rules/typescript/no-misused-new.md @@ -19,7 +19,8 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does Enforces valid definition of new and constructor. This rule prevents classes from defining -a method named `new` and interfaces from defining a method named `constructor`. +a method named `new`, interfaces from defining a method named `constructor`, and interfaces +from defining a construct signature that returns the interface itself. ### Why is this bad? @@ -27,7 +28,9 @@ JavaScript classes may define a constructor method that runs when a class instance is newly created. TypeScript allows interfaces that describe a static class object to -define a `new()` method (though this is rarely used in real world code). +define a `new()` signature (though this is rarely used in real world code). That construct +signature should return the constructed instance type, not the interface for the constructor +object itself. Developers new to JavaScript classes and/or TypeScript interfaces may sometimes confuse when to use constructor or new. @@ -44,6 +47,11 @@ declare class C { ```typescript interface I { new (): I; +} +``` + +```typescript +interface I { constructor(): void; } ``` @@ -57,6 +65,8 @@ declare class C { ``` ```typescript +class C {} + interface I { new (): C; } diff --git a/src/docs/guide/usage/linter/rules/unicorn/no-negated-condition.md b/src/docs/guide/usage/linter/rules/unicorn/no-negated-condition.md new file mode 100644 index 00000000000..c35ef406b94 --- /dev/null +++ b/src/docs/guide/usage/linter/rules/unicorn/no-negated-condition.md @@ -0,0 +1,63 @@ +--- +title: "unicorn/no-negated-condition" +category: "Pedantic" +version: "0.0.18" +default: false +type_aware: false +fix: "pending" +--- + + + + + + + +### What it does + +Disallow negated conditions. + +### Why is this bad? + +Negated conditions are more difficult to understand. Code can be made more readable by inverting the condition. + +### Examples + +Examples of **incorrect** code for this rule: + +```javascript +if (!a) { + doSomethingC(); +} else { + doSomethingB(); +} + +!a ? doSomethingC() : doSomethingB(); +``` + +Examples of **correct** code for this rule: + +```javascript +if (a) { + doSomethingB(); +} else { + doSomethingC(); +} + +a ? doSomethingB() : doSomethingC(); +``` + +## How to use + + + +## Version + +This rule was added in v0.0.18. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/unicorn/prefer-array-some.md b/src/docs/guide/usage/linter/rules/unicorn/prefer-array-some.md index 3f8116aaa24..f7787be1c5a 100644 --- a/src/docs/guide/usage/linter/rules/unicorn/prefer-array-some.md +++ b/src/docs/guide/usage/linter/rules/unicorn/prefer-array-some.md @@ -4,7 +4,7 @@ category: "Pedantic" version: "0.0.18" default: false type_aware: false -fix: "fixable_fix" +fix: "fixable_suggestion" --- diff --git a/src/docs/guide/usage/linter/rules/version.data.js b/src/docs/guide/usage/linter/rules/version.data.js index ef7f25673a9..5509d8a29bb 100644 --- a/src/docs/guide/usage/linter/rules/version.data.js +++ b/src/docs/guide/usage/linter/rules/version.data.js @@ -1,5 +1,5 @@ export default { load() { - return "2d102fd5badfd75cf879aae30bbe0129b8ac445a"; + return "d177595909fb9e3be6306335dba4046a94314cab"; }, }; diff --git a/src/docs/guide/usage/linter/rules/vitest/no-test-prefixes.md b/src/docs/guide/usage/linter/rules/vitest/no-test-prefixes.md new file mode 100644 index 00000000000..00e09db0df4 --- /dev/null +++ b/src/docs/guide/usage/linter/rules/vitest/no-test-prefixes.md @@ -0,0 +1,55 @@ +--- +title: "vitest/no-test-prefixes" +category: "Style" +version: "0.0.7" +default: false +type_aware: false +fix: "fixable_fix" +--- + + + + + + + +### What it does + +Require using `.only` and `.skip` over `f` and `x`. + +### Why is this bad? + +Jest allows you to choose how you want to define focused and skipped tests, +with multiple permutations for each: + +- only & skip: it.only, test.only, describe.only, it.skip, test.skip, describe.skip. +- 'f' & 'x': fit, fdescribe, xit, xtest, xdescribe. + +This rule enforces usages from the only & skip list. + +### Examples + +Examples of **incorrect** code for this rule: + +```javascript +fit("foo"); // invalid +fdescribe("foo"); // invalid +xit("foo"); // invalid +xtest("foo"); // invalid +xdescribe("foo"); // invalid +``` + +## How to use + + + +## Version + +This rule was added in v0.0.7. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/vitest/no-test-return-statement.md b/src/docs/guide/usage/linter/rules/vitest/no-test-return-statement.md new file mode 100644 index 00000000000..d30bf911188 --- /dev/null +++ b/src/docs/guide/usage/linter/rules/vitest/no-test-return-statement.md @@ -0,0 +1,57 @@ +--- +title: "vitest/no-test-return-statement" +category: "Style" +version: "0.2.0" +default: false +type_aware: false +fix: "none" +--- + + + + + + + +### What it does + +Disallow explicitly returning from tests. + +### Why is this bad? + +Tests in Jest should be void and not return values. +If you are returning Promises then you should update the test to use +`async/await`. + +### Examples + +Examples of **incorrect** code for this rule: + +```javascript +test("one", () => { + return expect(1).toBe(1); +}); +``` + +Examples of **correct** code for this rule: + +```javascript +test("one", () => { + expect(1).toBe(1); +}); +``` + +## How to use + + + +## Version + +This rule was added in v0.2.0. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/vitest/no-unneeded-async-expect-function.md b/src/docs/guide/usage/linter/rules/vitest/no-unneeded-async-expect-function.md new file mode 100644 index 00000000000..5f2d5845863 --- /dev/null +++ b/src/docs/guide/usage/linter/rules/vitest/no-unneeded-async-expect-function.md @@ -0,0 +1,57 @@ +--- +title: "vitest/no-unneeded-async-expect-function" +category: "Style" +version: "1.39.0" +default: false +type_aware: false +fix: "fixable_fix" +--- + + + + + + + +### What it does + +Disallows unnecessary async function wrapper for expected promises. + +### Why is this bad? + +When the only statement inside an async wrapper is `await someCall()`, +the call should be passed directly to `expect` instead. This makes the +test code more concise and easier to read. + +### Examples + +Examples of **incorrect** code for this rule: + +```js +await expect(async () => { + await doSomethingAsync(); +}).rejects.toThrow(); + +await expect(async () => await doSomethingAsync()).rejects.toThrow(); +``` + +Examples of **correct** code for this rule: + +```js +await expect(doSomethingAsync()).rejects.toThrow(); +``` + +## How to use + + + +## Version + +This rule was added in v1.39.0. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/vitest/prefer-called-with.md b/src/docs/guide/usage/linter/rules/vitest/prefer-called-with.md new file mode 100644 index 00000000000..ed48ec58174 --- /dev/null +++ b/src/docs/guide/usage/linter/rules/vitest/prefer-called-with.md @@ -0,0 +1,59 @@ +--- +title: "vitest/prefer-called-with" +category: "Style" +version: "0.2.5" +default: false +type_aware: false +fix: "fixable_fix" +--- + + + + + + + +### What it does + +Suggest using `toBeCalledWith()` or `toHaveBeenCalledWith()` + +### Why is this bad? + +When testing function calls, it's often more valuable to assert both +that a function was called AND what arguments it was called with. +Using `toBeCalled()` or `toHaveBeenCalled()` only verifies the function +was invoked, but doesn't validate the arguments, potentially missing +bugs where functions are called with incorrect parameters. + +### Examples + +Examples of **incorrect** code for this rule: + +```javascript +expect(someFunction).toBeCalled(); +expect(someFunction).toHaveBeenCalled(); +``` + +Examples of **correct** code for this rule: + +```javascript +expect(noArgsFunction).toBeCalledWith(); +expect(roughArgsFunction).toBeCalledWith(expect.anything(), expect.any(Date)); +expect(anyArgsFunction).toBeCalledTimes(1); +expect(uncalledFunction).not.toBeCalled(); +``` + +## How to use + + + +## Version + +This rule was added in v0.2.5. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/vitest/prefer-comparison-matcher.md b/src/docs/guide/usage/linter/rules/vitest/prefer-comparison-matcher.md new file mode 100644 index 00000000000..d6312773468 --- /dev/null +++ b/src/docs/guide/usage/linter/rules/vitest/prefer-comparison-matcher.md @@ -0,0 +1,66 @@ +--- +title: "vitest/prefer-comparison-matcher" +category: "Style" +version: "0.2.15" +default: false +type_aware: false +fix: "fixable_fix" +--- + + + + + + + +### What it does + +This rule checks for comparisons in tests that could be replaced with one of the +following built-in comparison matchers: + +- `toBeGreaterThan` +- `toBeGreaterThanOrEqual` +- `toBeLessThan` +- `toBeLessThanOrEqual` + +### Why is this bad? + +Using generic matchers like `toBe(true)` with comparison expressions +makes tests less readable and provides less helpful error messages when +they fail. Jest's specific comparison matchers offer clearer intent and +better error output that shows the actual values being compared. + +### Examples + +Examples of **incorrect** code for this rule: + +```js +expect(x > 5).toBe(true); +expect(x < 7).not.toEqual(true); +expect(x <= y).toStrictEqual(true); +``` + +Examples of **correct** code for this rule: + +```js +expect(x).toBeGreaterThan(5); +expect(x).not.toBeLessThanOrEqual(7); +expect(x).toBeLessThanOrEqual(y); +// special case - see below +expect(x < "Carl").toBe(true); +``` + +## How to use + + + +## Version + +This rule was added in v0.2.15. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/vitest/prefer-each.md b/src/docs/guide/usage/linter/rules/vitest/prefer-each.md new file mode 100644 index 00000000000..90b58f48c42 --- /dev/null +++ b/src/docs/guide/usage/linter/rules/vitest/prefer-each.md @@ -0,0 +1,59 @@ +--- +title: "vitest/prefer-each" +category: "Style" +version: "0.9.0" +default: false +type_aware: false +fix: "none" +--- + + + + + + + +### What it does + +This rule enforces using `each` rather than manual loops. + +### Why is this bad? + +Manual loops for tests can be less readable and more error-prone. Using +`each` provides a clearer and more concise way to run parameterized tests, +improving readability and maintainability. + +### Examples + +Examples of **incorrect** code for this rule: + +```js +for (const item of items) { + describe(item, () => { + expect(item).toBe("foo"); + }); +} +``` + +Examples of **correct** code for this rule: + +```js +describe.each(items)("item", (item) => { + expect(item).toBe("foo"); +}); +``` + +## How to use + + + +## Version + +This rule was added in v0.9.0. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/vitest/prefer-equality-matcher.md b/src/docs/guide/usage/linter/rules/vitest/prefer-equality-matcher.md new file mode 100644 index 00000000000..451fe92f81d --- /dev/null +++ b/src/docs/guide/usage/linter/rules/vitest/prefer-equality-matcher.md @@ -0,0 +1,60 @@ +--- +title: "vitest/prefer-equality-matcher" +category: "Style" +version: "0.2.9" +default: false +type_aware: false +fix: "fixable_suggestion" +--- + + + + + + + +### What it does + +Jest has built-in matchers for expecting equality, which allow for more readable +tests and error messages if an expectation fails. + +### Why is this bad? + +Testing equality expressions with generic matchers like `toBe(true)` +makes tests harder to read and understand. When tests fail, the error +messages are less helpful because they don't show what the actual values +were. Using specific equality matchers provides clearer test intent and +better debugging information. + +### Examples + +Examples of **incorrect** code for this rule: + +```javascript +expect(x === 5).toBe(true); +expect(name === "Carl").not.toEqual(true); +expect(myObj !== thatObj).toStrictEqual(true); +``` + +Examples of **correct** code for this rule: + +```javascript +expect(x).toBe(5); +expect(name).not.toEqual("Carl"); +expect(myObj).toStrictEqual(thatObj); +``` + +## How to use + + + +## Version + +This rule was added in v0.2.9. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/vitest/prefer-expect-resolves.md b/src/docs/guide/usage/linter/rules/vitest/prefer-expect-resolves.md new file mode 100644 index 00000000000..652fd3b47ba --- /dev/null +++ b/src/docs/guide/usage/linter/rules/vitest/prefer-expect-resolves.md @@ -0,0 +1,81 @@ +--- +title: "vitest/prefer-expect-resolves" +category: "Style" +version: "0.2.14" +default: false +type_aware: false +fix: "fixable_fix" +--- + + + + + + + +### What it does + +Prefer `await expect(...).resolves` over `expect(await ...)` when testing +promises. + +### Why is this bad? + +When working with promises, there are two primary ways you can test the +resolved value: + +1. use the `resolve` modifier on `expect` + (`await expect(...).resolves.` style) +2. `await` the promise and assert against its result + (`expect(await ...).` style) + +While the second style is arguably less dependent on `jest`, if the +promise rejects it will be treated as a general error, resulting in less +predictable behaviour and output from `jest`. + +Additionally, favoring the first style ensures consistency with its +`rejects` counterpart, as there is no way of "awaiting" a rejection. + +### Examples + +Examples of **incorrect** code for this rule: + +```javascript +it("passes", async () => { + expect(await someValue()).toBe(true); +}); +it("is true", async () => { + const myPromise = Promise.resolve(true); + expect(await myPromise).toBe(true); +}); +``` + +Examples of **correct** code for this rule: + +```javascript +it("passes", async () => { + await expect(someValue()).resolves.toBe(true); +}); +it("is true", async () => { + const myPromise = Promise.resolve(true); + + await expect(myPromise).resolves.toBe(true); +}); +it("errors", async () => { + await expect(Promise.reject(new Error("oh noes!"))).rejects.toThrowError("oh noes!"); +}); +``` + +## How to use + + + +## Version + +This rule was added in v0.2.14. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/vitest/prefer-hooks-in-order.md b/src/docs/guide/usage/linter/rules/vitest/prefer-hooks-in-order.md new file mode 100644 index 00000000000..353e3105d4c --- /dev/null +++ b/src/docs/guide/usage/linter/rules/vitest/prefer-hooks-in-order.md @@ -0,0 +1,134 @@ +--- +title: "vitest/prefer-hooks-in-order" +category: "Style" +version: "0.6.0" +default: false +type_aware: false +fix: "none" +--- + + + + + + + +### What it does + +Ensures that hooks are in the order that they are called in. + +### Why is this bad? + +While hooks can be setup in any order, they're always called by `jest` in this +specific order: + +1. `beforeAll` +2. `beforeEach` +3. `afterEach` +4. `afterAll` + +This rule aims to make that more obvious by enforcing grouped hooks be setup in +that order within tests. + +### Examples + +Examples of **incorrect** code for this rule: + +```javascript +describe("foo", () => { + beforeEach(() => { + seedMyDatabase(); + }); + beforeAll(() => { + createMyDatabase(); + }); + it("accepts this input", () => { + // ... + }); + it("returns that value", () => { + // ... + }); + describe("when the database has specific values", () => { + const specificValue = "..."; + beforeEach(() => { + seedMyDatabase(specificValue); + }); + it("accepts that input", () => { + // ... + }); + it("throws an error", () => { + // ... + }); + afterEach(() => { + clearLogger(); + }); + beforeEach(() => { + mockLogger(); + }); + it("logs a message", () => { + // ... + }); + }); + afterAll(() => { + removeMyDatabase(); + }); +}); +``` + +Examples of **correct** code for this rule: + +```javascript +describe("foo", () => { + beforeAll(() => { + createMyDatabase(); + }); + beforeEach(() => { + seedMyDatabase(); + }); + it("accepts this input", () => { + // ... + }); + it("returns that value", () => { + // ... + }); + describe("when the database has specific values", () => { + const specificValue = "..."; + beforeEach(() => { + seedMyDatabase(specificValue); + }); + it("accepts that input", () => { + // ... + }); + it("throws an error", () => { + // ... + }); + beforeEach(() => { + mockLogger(); + }); + afterEach(() => { + clearLogger(); + }); + it("logs a message", () => { + // ... + }); + }); + afterAll(() => { + removeMyDatabase(); + }); +}); +``` + +## How to use + + + +## Version + +This rule was added in v0.6.0. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/vitest/prefer-hooks-on-top.md b/src/docs/guide/usage/linter/rules/vitest/prefer-hooks-on-top.md new file mode 100644 index 00000000000..39a949e4583 --- /dev/null +++ b/src/docs/guide/usage/linter/rules/vitest/prefer-hooks-on-top.md @@ -0,0 +1,152 @@ +--- +title: "vitest/prefer-hooks-on-top" +category: "Style" +version: "0.4.2" +default: false +type_aware: false +fix: "none" +--- + + + + + + + +### What it does + +While hooks can be setup anywhere in a test file, they are always called in a +specific order, which means it can be confusing if they're intermixed with test +cases. + +### Why is this bad? + +When hooks are mixed with test cases, it becomes harder to understand +the test setup and execution order. This can lead to confusion about +which hooks apply to which tests and when they run. Grouping hooks at +the top of each `describe` block makes the test structure clearer and +more maintainable. + +### Examples + +Examples of **incorrect** code for this rule: + +```javascript +describe("foo", () => { + beforeEach(() => { + seedMyDatabase(); + }); + + it("accepts this input", () => { + // ... + }); + + beforeAll(() => { + createMyDatabase(); + }); + + it("returns that value", () => { + // ... + }); + + describe("when the database has specific values", () => { + const specificValue = "..."; + beforeEach(() => { + seedMyDatabase(specificValue); + }); + + it("accepts that input", () => { + // ... + }); + + it("throws an error", () => { + // ... + }); + + afterEach(() => { + clearLogger(); + }); + + beforeEach(() => { + mockLogger(); + }); + + it("logs a message", () => { + // ... + }); + }); + + afterAll(() => { + removeMyDatabase(); + }); +}); +``` + +Examples of **correct** code for this rule: + +```javascript +describe("foo", () => { + beforeAll(() => { + createMyDatabase(); + }); + + beforeEach(() => { + seedMyDatabase(); + }); + + afterAll(() => { + clearMyDatabase(); + }); + + it("accepts this input", () => { + // ... + }); + + it("returns that value", () => { + // ... + }); + + describe("when the database has specific values", () => { + const specificValue = "..."; + + beforeEach(() => { + seedMyDatabase(specificValue); + }); + + beforeEach(() => { + mockLogger(); + }); + + afterEach(() => { + clearLogger(); + }); + + it("accepts that input", () => { + // ... + }); + + it("throws an error", () => { + // ... + }); + + it("logs a message", () => { + // ... + }); + }); +}); +``` + +## How to use + + + +## Version + +This rule was added in v0.4.2. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/vitest/prefer-lowercase-title.md b/src/docs/guide/usage/linter/rules/vitest/prefer-lowercase-title.md new file mode 100644 index 00000000000..db5b87e029e --- /dev/null +++ b/src/docs/guide/usage/linter/rules/vitest/prefer-lowercase-title.md @@ -0,0 +1,173 @@ +--- +title: "vitest/prefer-lowercase-title" +category: "Style" +version: "0.15.9" +default: false +type_aware: false +fix: "fixable_fix" +--- + + + + + + + +### What it does + +Enforce `it`, `test`, `describe`, and `bench` to have descriptions that begin with a +lowercase letter. This provides more readable test failures. + +### Why is this bad? + +Lowercase messages for test failures generally result in more grammatically correct +failure messages when you have a test failure. + +### Examples + +Examples of **incorrect** code for this rule: + +```javascript +it("Adds 1 + 2 to equal 3", () => { + expect(sum(1, 2)).toBe(3); +}); +``` + +Examples of **correct** code for this rule: + +```javascript +it("adds 1 + 2 to equal 3", () => { + expect(sum(1, 2)).toBe(3); +}); +``` + +## Configuration + +This rule accepts a configuration object with the following properties: + +### allowedPrefixes + +type: `string[]` + +default: `[]` + +This array option allows specifying prefixes, which contain capitals that titles +can start with. This can be useful when writing tests for API endpoints, where +you'd like to prefix with the HTTP method. +By default, nothing is allowed (the equivalent of `{ "allowedPrefixes": [] }`). + +Example of **correct** code for the `{ "allowedPrefixes": ["GET"] }` option: + +```js +/* jest/prefer-lowercase-title: ["error", { "allowedPrefixes": ["GET"] }] */ +describe("GET /live"); +``` + +### ignore + +type: `string[]` + +default: `[]` + +This array option controls which Jest or Vitest functions are checked by this rule. There +are four possible values: + +- `"describe"` +- `"test"` +- `"it"` +- `"bench"` + +By default, none of these options are enabled (the equivalent of +`{ "ignore": [] }`). + +Example of **correct** code for the `{ "ignore": ["describe"] }` option: + +```js +/* jest/prefer-lowercase-title: ["error", { "ignore": ["describe"] }] */ +describe("Uppercase description"); +``` + +Example of **correct** code for the `{ "ignore": ["test"] }` option: + +```js +/* jest/prefer-lowercase-title: ["error", { "ignore": ["test"] }] */ +test("Uppercase description"); +``` + +Example of **correct** code for the `{ "ignore": ["it"] }` option: + +```js +/* jest/prefer-lowercase-title: ["error", { "ignore": ["it"] }] */ +it("Uppercase description"); +``` + +### ignoreTopLevelDescribe + +type: `boolean` + +default: `false` + +This option can be set to allow only the top-level `describe` blocks to have a +title starting with an upper-case letter. + +Example of **correct** code for the `{ "ignoreTopLevelDescribe": true }` option: + +```js +/* jest/prefer-lowercase-title: ["error", { "ignoreTopLevelDescribe": true }] */ +describe("MyClass", () => { + describe("#myMethod", () => { + it("does things", () => { + // + }); + }); +}); +``` + +### lowercaseFirstCharacterOnly + +type: `boolean` + +default: `true` + +This option can be set to only validate that the first character of a test name is lowercased. + +Example of **correct** code for the `{ "lowercaseFirstCharacterOnly": true }` option: + +```js +/* vitest/prefer-lowercase-title: ["error", { "lowercaseFirstCharacterOnly": true }] */ +describe("myClass", () => { + describe("myMethod", () => { + it("does things", () => { + // + }); + }); +}); +``` + +Example of **incorrect** code for the `{ "lowercaseFirstCharacterOnly": true }` option: + +```js +/* vitest/prefer-lowercase-title: ["error", { "lowercaseFirstCharacterOnly": true }] */ +describe("MyClass", () => { + describe("MyMethod", () => { + it("does things", () => { + // + }); + }); +}); +``` + +## How to use + + + +## Version + +This rule was added in v0.15.9. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/vitest/prefer-mock-promise-shorthand.md b/src/docs/guide/usage/linter/rules/vitest/prefer-mock-promise-shorthand.md new file mode 100644 index 00000000000..d2bcc5efcaa --- /dev/null +++ b/src/docs/guide/usage/linter/rules/vitest/prefer-mock-promise-shorthand.md @@ -0,0 +1,69 @@ +--- +title: "vitest/prefer-mock-promise-shorthand" +category: "Style" +version: "0.2.16" +default: false +type_aware: false +fix: "conditional_fix" +--- + + + + + + + +### What it does + +When working with mocks of functions that return promises, Jest provides some +API sugar functions to reduce the amount of boilerplate you have to write. +These methods should be preferred when possible. + +### Why is this bad? + +Using generic mock functions like `mockImplementation(() => Promise.resolve())` +or `mockReturnValue(Promise.reject())` is more verbose and less readable than +Jest's specialized promise shorthands. The shorthand methods like +`mockResolvedValue()` and `mockRejectedValue()` are more expressive and +make the test intent clearer. + +### Examples + +Examples of **incorrect** code for this rule: + +```javascript +jest.fn().mockImplementation(() => Promise.resolve(123)); +jest.spyOn(fs.promises, "readFile").mockReturnValue(Promise.reject(new Error("oh noes!"))); + +myFunction + .mockReturnValueOnce(Promise.resolve(42)) + .mockImplementationOnce(() => Promise.resolve(42)) + .mockReturnValue(Promise.reject(new Error("too many calls!"))); +``` + +Examples of **correct** code for this rule: + +```javascript +jest.fn().mockResolvedValue(123); +jest.spyOn(fs.promises, "readFile").mockRejectedValue(new Error("oh noes!")); + +myFunction + .mockResolvedValueOnce(42) + .mockResolvedValueOnce(42) + .mockRejectedValue(new Error("too many calls!")); +``` + +## How to use + + + +## Version + +This rule was added in v0.2.16. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/vitest/prefer-mock-return-shorthand.md b/src/docs/guide/usage/linter/rules/vitest/prefer-mock-return-shorthand.md new file mode 100644 index 00000000000..925c1a4e861 --- /dev/null +++ b/src/docs/guide/usage/linter/rules/vitest/prefer-mock-return-shorthand.md @@ -0,0 +1,70 @@ +--- +title: "vitest/prefer-mock-return-shorthand" +category: "Style" +version: "1.49.0" +default: false +type_aware: false +fix: "fixable_fix" +--- + + + + + + + +### What it does + +When working with mocks of functions that return simple values, Jest provides some API sugar functions to reduce the amount of boilerplate you have to write. + +### Why is this bad? + +Not using Jest's API sugar functions adds unnecessary boilerplate and makes tests harder to read. These helpers clearly express intent +and reduce errors, keeping tests simple and maintainable. + +### Examples + +Examples of **incorrect** code for this rule: + +```js +jest.fn().mockImplementation(() => "hello world"); + +jest + .spyOn(fs.promises, "readFile") + .mockImplementationOnce(() => Promise.reject(new Error("oh noes!"))); + +myFunction + .mockImplementationOnce(() => 42) + .mockImplementationOnce(() => Promise.resolve(42)) + .mockReturnValue(0); +``` + +Examples of **correct** code for this rule: + +```js +jest.fn().mockResolvedValue(123); + +jest.spyOn(fs.promises, "readFile").mockReturnValue(Promise.reject(new Error("oh noes!"))); +jest.spyOn(fs.promises, "readFile").mockRejectedValue(new Error("oh noes!")); + +jest.spyOn(fs, "readFileSync").mockImplementationOnce(() => { + throw new Error("oh noes!"); +}); + +myFunction.mockResolvedValueOnce(42).mockResolvedValueOnce(42).mockReturnValue(0); +``` + +## How to use + + + +## Version + +This rule was added in v1.49.0. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/vitest/prefer-snapshot-hint.md b/src/docs/guide/usage/linter/rules/vitest/prefer-snapshot-hint.md new file mode 100644 index 00000000000..23cf6b08f11 --- /dev/null +++ b/src/docs/guide/usage/linter/rules/vitest/prefer-snapshot-hint.md @@ -0,0 +1,207 @@ +--- +title: "vitest/prefer-snapshot-hint" +category: "Correctness" +version: "1.59.0" +default: false +type_aware: false +fix: "none" +--- + + + + + + + +### What it does + +Enforces including a hint string with snapshot matchers (toMatchSnapshot and toThrowErrorMatchingSnapshot). + +### Why is this bad? + +Auto-numbered snapshot names are fragile — adding or reordering assertions shifts all subsequent numbers, causing unrelated snapshots to appear changed and obscuring real differences in code review. + +### Examples + +Examples of **incorrect** code for this rule configured as `always`: + +```js +const snapshotOutput = ({ stdout, stderr }) => { + expect(stdout).toMatchSnapshot(); + expect(stderr).toMatchSnapshot(); +}; + +describe("cli", () => { + describe("--version flag", () => { + it("prints the version", async () => { + snapshotOutput(await runCli(["--version"])); + }); + }); + + describe("--config flag", () => { + it("reads the config", async () => { + const { stdout, parsedConfig } = await runCli(["--config", "jest.config.js"]); + + expect(stdout).toMatchSnapshot(); + expect(parsedConfig).toMatchSnapshot(); + }); + + it("prints nothing to stderr", async () => { + const { stderr } = await runCli(["--config", "jest.config.js"]); + + expect(stderr).toMatchSnapshot(); + }); + + describe("when the file does not exist", () => { + it("throws an error", async () => { + await expect( + runCli(["--config", "does-not-exist.js"]), + ).rejects.toThrowErrorMatchingSnapshot(); + }); + }); + }); +}); +``` + +Examples of **incorrect** code for this rule configured as `multi`: + +```js +const snapshotOutput = ({ stdout, stderr }) => { + expect(stdout).toMatchSnapshot(); + expect(stderr).toMatchSnapshot(); +}; + +describe("cli", () => { + describe("--version flag", () => { + it("prints the version", async () => { + snapshotOutput(await runCli(["--version"])); + }); + }); + + describe("--config flag", () => { + it("reads the config", async () => { + const { stdout, parsedConfig } = await runCli(["--config", "jest.config.js"]); + + expect(stdout).toMatchSnapshot(); + expect(parsedConfig).toMatchSnapshot(); + }); + + it("prints nothing to stderr", async () => { + const { stderr } = await runCli(["--config", "jest.config.js"]); + + expect(stderr).toMatchSnapshot(); + }); + }); +}); +``` + +Examples of **correct** code for this rule configured as `always`: + +```js +const snapshotOutput = ({ stdout, stderr }, hints) => { + expect(stdout).toMatchSnapshot({}, `stdout: ${hints.stdout}`); + expect(stderr).toMatchSnapshot({}, `stderr: ${hints.stderr}`); +}; + +describe("cli", () => { + describe("--version flag", () => { + it("prints the version", async () => { + snapshotOutput(await runCli(["--version"]), { + stdout: "version string", + stderr: "empty", + }); + }); + }); + + describe("--config flag", () => { + it("reads the config", async () => { + const { stdout } = await runCli(["--config", "jest.config.js"]); + + expect(stdout).toMatchSnapshot({}, "stdout: config settings"); + }); + + it("prints nothing to stderr", async () => { + const { stderr } = await runCli(["--config", "jest.config.js"]); + + expect(stderr).toMatchInlineSnapshot(); + }); + + describe("when the file does not exist", () => { + it("throws an error", async () => { + await expect( + runCli(["--config", "does-not-exist.js"]), + ).rejects.toThrowErrorMatchingSnapshot("stderr: config error"); + }); + }); + }); +}); +``` + +Examples of **correct** code for this rule configured as `multi`: + +```js +const snapshotOutput = ({ stdout, stderr }, hints) => { + expect(stdout).toMatchSnapshot({}, `stdout: ${hints.stdout}`); + expect(stderr).toMatchSnapshot({}, `stderr: ${hints.stderr}`); +}; + +describe("cli", () => { + describe("--version flag", () => { + it("prints the version", async () => { + snapshotOutput(await runCli(["--version"]), { + stdout: "version string", + stderr: "empty", + }); + }); + }); + + describe("--config flag", () => { + it("reads the config", async () => { + const { stdout } = await runCli(["--config", "jest.config.js"]); + + expect(stdout).toMatchSnapshot(); + }); + + it("prints nothing to stderr", async () => { + const { stderr } = await runCli(["--config", "jest.config.js"]); + + expect(stderr).toMatchInlineSnapshot(); + }); + + describe("when the file does not exist", () => { + it("throws an error", async () => { + await expect( + runCli(["--config", "does-not-exist.js"]), + ).rejects.toThrowErrorMatchingSnapshot(); + }); + }); + }); +}); +``` + +## Configuration + +This rule accepts one of the following string values: + +### `"always"` + +Require a hint to always be provided when using external snapshot matchers. + +### `"multi"` + +Require a hint to be provided when there are multiple external snapshot matchers within the scope (meaning it includes nested calls). + +## How to use + + + +## Version + +This rule was added in v1.59.0. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/vitest/prefer-spy-on.md b/src/docs/guide/usage/linter/rules/vitest/prefer-spy-on.md new file mode 100644 index 00000000000..d133a3dc168 --- /dev/null +++ b/src/docs/guide/usage/linter/rules/vitest/prefer-spy-on.md @@ -0,0 +1,66 @@ +--- +title: "vitest/prefer-spy-on" +category: "Style" +version: "0.2.14" +default: false +type_aware: false +fix: "fixable_suggestion" +--- + + + + + + + +### What it does + +When mocking a function by overwriting a property you have to manually restore +the original implementation when cleaning up. When using `jest.spyOn()` Jest +keeps track of changes, and they can be restored with `jest.restoreAllMocks()`, +`mockFn.mockRestore()` or by setting `restoreMocks` to `true` in the Jest +config. + +Note: The mock created by `jest.spyOn()` still behaves the same as the original +function. The original function can be overwritten with +`mockFn.mockImplementation()` or by some of the +[other mock functions](https://jestjs.io/docs/en/mock-function-api). + +### Why is this bad? + +Directly overwriting properties with mock functions can lead to cleanup issues +and test isolation problems. When you manually assign a mock to a property, +you're responsible for restoring the original implementation, which is easy to +forget and can cause tests to interfere with each other. Using `jest.spyOn()` +provides automatic cleanup capabilities and makes your tests more reliable. + +### Examples + +Examples of **incorrect** code for this rule: + +```javascript +Date.now = jest.fn(); +Date.now = jest.fn(() => 10); +``` + +Examples of **correct** code for this rule: + +```javascript +jest.spyOn(Date, "now"); +jest.spyOn(Date, "now").mockImplementation(() => 10); +``` + +## How to use + + + +## Version + +This rule was added in v0.2.14. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/vitest/prefer-strict-equal.md b/src/docs/guide/usage/linter/rules/vitest/prefer-strict-equal.md new file mode 100644 index 00000000000..72d5140f41a --- /dev/null +++ b/src/docs/guide/usage/linter/rules/vitest/prefer-strict-equal.md @@ -0,0 +1,54 @@ +--- +title: "vitest/prefer-strict-equal" +category: "Style" +version: "0.2.13" +default: false +type_aware: false +fix: "fixable_fix" +--- + + + + + + + +### What it does + +This rule triggers a warning if `toEqual()` is used to assert equality. + +### Why is this bad? + +The `toEqual()` matcher performs a deep equality check but ignores +`undefined` values in objects and arrays. This can lead to false +positives where tests pass when they should fail. `toStrictEqual()` +provides more accurate comparison by checking for `undefined` values. + +### Examples + +Examples of **incorrect** code for this rule: + +```javascript +expect({ a: "a", b: undefined }).toEqual({ a: "a" }); +``` + +Examples of **correct** code for this rule: + +```javascript +expect({ a: "a", b: undefined }).toStrictEqual({ a: "a" }); +``` + +## How to use + + + +## Version + +This rule was added in v0.2.13. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/vitest/prefer-to-be.md b/src/docs/guide/usage/linter/rules/vitest/prefer-to-be.md new file mode 100644 index 00000000000..1c0b074af0a --- /dev/null +++ b/src/docs/guide/usage/linter/rules/vitest/prefer-to-be.md @@ -0,0 +1,65 @@ +--- +title: "vitest/prefer-to-be" +category: "Style" +version: "0.2.14" +default: false +type_aware: false +fix: "fixable_fix" +--- + + + + + + + +### What it does + +Recommends using `toBe` matcher for primitive literals and specific +matchers for `null`, `undefined`, and `NaN`. + +### Why is this bad? + +When asserting against primitive literals such as numbers and strings, +the equality matchers all operate the same, but read slightly +differently in code. + +This rule recommends using the `toBe` matcher in these situations, as +it forms the most grammatically natural sentence. For `null`, +`undefined`, and `NaN` this rule recommends using their specific `toBe` +matchers, as they give better error messages as well. + +### Examples + +Examples of **incorrect** code for this rule: + +```javascript +expect(value).not.toEqual(5); +expect(getMessage()).toStrictEqual("hello world"); +expect(loadMessage()).resolves.toEqual("hello world"); +``` + +Examples of **correct** code for this rule: + +```javascript +expect(value).not.toBe(5); +expect(getMessage()).toBe("hello world"); +expect(loadMessage()).resolves.toBe("hello world"); +expect(didError).not.toBe(true); +expect(catchError()).toStrictEqual({ message: "oh noes!" }); +``` + +## How to use + + + +## Version + +This rule was added in v0.2.14. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/vitest/prefer-to-have-been-called-times.md b/src/docs/guide/usage/linter/rules/vitest/prefer-to-have-been-called-times.md new file mode 100644 index 00000000000..0d13d262688 --- /dev/null +++ b/src/docs/guide/usage/linter/rules/vitest/prefer-to-have-been-called-times.md @@ -0,0 +1,58 @@ +--- +title: "vitest/prefer-to-have-been-called-times" +category: "Style" +version: "1.34.0" +default: false +type_aware: false +fix: "fixable_fix" +--- + + + + + + + +### What it does + +In order to have a better failure message, [`toHaveBeenCalledTimes` should be used +instead of directly checking the length of `mock.calls`](https://github.com/jest-community/eslint-plugin-jest/blob/v29.5.0/docs/rules/prefer-to-have-been-called-times.md). + +### Why is this bad? + +This rule triggers a warning if `toHaveLength` is used to assert the number of times a mock is called. + +### Examples + +Examples of **incorrect** code for this rule: + +```js +expect(someFunction.mock.calls).toHaveLength(1); +expect(someFunction.mock.calls).toHaveLength(0); +expect(someFunction.mock.calls).not.toHaveLength(1); +``` + +Examples of **correct** code for this rule: + +```js +expect(someFunction).toHaveBeenCalledTimes(1); +expect(someFunction).toHaveBeenCalledTimes(0); +expect(someFunction).not.toHaveBeenCalledTimes(0); +expect(uncalledFunction).not.toBeCalled(); +expect(method.mock.calls[0][0]).toStrictEqual(value); +``` + +## How to use + + + +## Version + +This rule was added in v1.34.0. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/vitest/prefer-to-have-length.md b/src/docs/guide/usage/linter/rules/vitest/prefer-to-have-length.md new file mode 100644 index 00000000000..7e132936b36 --- /dev/null +++ b/src/docs/guide/usage/linter/rules/vitest/prefer-to-have-length.md @@ -0,0 +1,55 @@ +--- +title: "vitest/prefer-to-have-length" +category: "Style" +version: "0.2.13" +default: false +type_aware: false +fix: "fixable_fix" +--- + + + + + + + +### What it does + +In order to have a better failure message, `toHaveLength()` should be used upon +asserting expectations on objects length property. + +### Why is this bad? + +This rule triggers a warning if `toBe()`, `toEqual()` or `toStrictEqual()` is +used to assert objects length property. + +### Examples + +Examples of **incorrect** code for this rule: + +```javascript +expect(files["length"]).toBe(1); +expect(files["length"]).toBe(1); +expect(files["length"])["not"].toBe(1); +``` + +Examples of **correct** code for this rule: + +```javascript +expect(files).toHaveLength(1); +``` + +## How to use + + + +## Version + +This rule was added in v0.2.13. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/vitest/require-hook.md b/src/docs/guide/usage/linter/rules/vitest/require-hook.md new file mode 100644 index 00000000000..2bd182a0cc2 --- /dev/null +++ b/src/docs/guide/usage/linter/rules/vitest/require-hook.md @@ -0,0 +1,159 @@ +--- +title: "vitest/require-hook" +category: "Style" +version: "0.3.2" +default: false +type_aware: false +fix: "none" +--- + + + + + + + +### What it does + +This rule flags any expression that is either at the toplevel of a test file or +directly within the body of a `describe`, _except_ for the following: + +- `import` statements +- `const` variables +- `let` _declarations_, and initializations to `null` or `undefined` +- Classes +- Types +- Calls to the standard Jest globals + +### Why is this bad? + +Having setup and teardown code outside of hooks can lead to unpredictable test +behavior. Code that runs at the top level executes when the test file is loaded, +not when tests run, which can cause issues with test isolation and make tests +dependent on execution order. Using proper hooks like `beforeEach`, `beforeAll`, +`afterEach`, and `afterAll` ensures that setup and teardown code runs at the +correct time and maintains test isolation. + +### Examples + +Examples of **incorrect** code for this rule: + +```javascript +import { database, isCity } from "../database"; +import { Logger } from "../../../src/Logger"; +import { loadCities } from "../api"; + +jest.mock("../api"); + +const initializeCityDatabase = () => { + database.addCity("Vienna"); + database.addCity("San Juan"); + database.addCity("Wellington"); +}; + +const clearCityDatabase = () => { + database.clear(); +}; + +initializeCityDatabase(); + +test("that persists cities", () => { + expect(database.cities.length).toHaveLength(3); +}); +test("city database has Vienna", () => { + expect(isCity("Vienna")).toBeTruthy(); +}); + +test("city database has San Juan", () => { + expect(isCity("San Juan")).toBeTruthy(); +}); + +describe("when loading cities from the api", () => { + let consoleWarnSpy = jest.spyOn(console, "warn"); + loadCities.mockResolvedValue(["Wellington", "London"]); + + it("does not duplicate cities", async () => { + await database.loadCities(); + expect(database.cities).toHaveLength(4); + }); +}); +clearCityDatabase(); +``` + +Examples of **correct** code for this rule: + +```javascript +import { database, isCity } from "../database"; +import { Logger } from "../../../src/Logger"; +import { loadCities } from "../api"; + +jest.mock("../api"); +const initializeCityDatabase = () => { + database.addCity("Vienna"); + database.addCity("San Juan"); + database.addCity("Wellington"); +}; + +const clearCityDatabase = () => { + database.clear(); +}; + +beforeEach(() => { + initializeCityDatabase(); +}); + +test("that persists cities", () => { + expect(database.cities.length).toHaveLength(3); +}); + +test("city database has Vienna", () => { + expect(isCity("Vienna")).toBeTruthy(); +}); + +test("city database has San Juan", () => { + expect(isCity("San Juan")).toBeTruthy(); +}); + +describe("when loading cities from the api", () => { + let consoleWarnSpy; + beforeEach(() => { + consoleWarnSpy = jest.spyOn(console, "warn"); + loadCities.mockResolvedValue(["Wellington", "London"]); + }); + + it("does not duplicate cities", async () => { + await database.loadCities(); + expect(database.cities).toHaveLength(4); + }); +}); +afterEach(() => { + clearCityDatabase(); +}); +``` + +## Configuration + +This rule accepts a configuration object with the following properties: + +### allowedFunctionCalls + +type: `string[]` + +default: `[]` + +An array of function names that are allowed to be called outside of hooks. + +## How to use + + + +## Version + +This rule was added in v0.3.2. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/vitest/require-to-throw-message.md b/src/docs/guide/usage/linter/rules/vitest/require-to-throw-message.md new file mode 100644 index 00000000000..845e21adb7b --- /dev/null +++ b/src/docs/guide/usage/linter/rules/vitest/require-to-throw-message.md @@ -0,0 +1,65 @@ +--- +title: "vitest/require-to-throw-message" +category: "Correctness" +version: "0.2.9" +default: false +type_aware: false +fix: "none" +--- + + + + + + + +### What it does + +This rule triggers a warning if `toThrow()` or `toThrowError()` is used without an error message. + +### Why is this bad? + +Using `toThrow()` or `toThrowError()` without specifying an expected error message +makes tests less specific and harder to debug. When a test only checks that an +error was thrown but not what kind of error, it can pass even when the wrong +error is thrown, potentially hiding bugs. Providing an expected error message +or error type makes tests more precise and helps catch regressions more effectively. + +### Examples + +Examples of **incorrect** code for this rule: + +```javascript +test("all the things", async () => { + expect(() => a()).toThrow(); + expect(() => a()).toThrowError(); + await expect(a()).rejects.toThrow(); + await expect(a()).rejects.toThrowError(); +}); +``` + +Examples of **correct** code for this rule: + +```javascript +test("all the things", async () => { + expect(() => a()).toThrow("a"); + expect(() => a()).toThrowError("a"); + await expect(a()).rejects.toThrow("a"); + await expect(a()).rejects.toThrowError("a"); +}); +``` + +## How to use + + + +## Version + +This rule was added in v0.2.9. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/vitest/valid-describe-callback.md b/src/docs/guide/usage/linter/rules/vitest/valid-describe-callback.md new file mode 100644 index 00000000000..ac6c993edf3 --- /dev/null +++ b/src/docs/guide/usage/linter/rules/vitest/valid-describe-callback.md @@ -0,0 +1,66 @@ +--- +title: "vitest/valid-describe-callback" +category: "Correctness" +version: "0.0.8" +default: false +type_aware: false +fix: "none" +--- + + + + + + + +### What it does + +This rule validates that the second parameter of a `describe()` function is a +callback function. This callback function: + +- should not be + [async](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function) +- should not contain any parameters +- should not contain any `return` statements + +### Why is this bad? + +Using an improper `describe()` callback function can lead to unexpected test +errors. + +### Examples + +Examples of **incorrect** code for this rule: + +```javascript +// Async callback functions are not allowed +describe("myFunction()", async () => { + // ... +}); + +// Callback function parameters are not allowed +describe("myFunction()", (done) => { + // ... +}); + +// Returning a value from a describe block is not allowed +describe("myFunction", () => + it("returns a truthy value", () => { + expect(myFunction()).toBeTruthy(); + })); +``` + +## How to use + + + +## Version + +This rule was added in v0.0.8. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/vue/no-deprecated-model-definition.md b/src/docs/guide/usage/linter/rules/vue/no-deprecated-model-definition.md new file mode 100644 index 00000000000..92d8f82e943 --- /dev/null +++ b/src/docs/guide/usage/linter/rules/vue/no-deprecated-model-definition.md @@ -0,0 +1,85 @@ +--- +title: "vue/no-deprecated-model-definition" +category: "Correctness" +version: "next" +default: false +type_aware: false +fix: "pending" +--- + + + + + + + +### What it does + +Disallow deprecated `model` definition (in Vue.js 3.0.0+). + +### Why is this bad? + +Vue 3 removed the per-component `model` option. Instead, `v-model` +works through the `modelValue` prop and the `update:modelValue` event, +so a `model: { prop, event }` block is no longer needed. + +With `{ "allowVue3Compat": true }`, a `model` block is allowed if it +already uses the Vue 3-compatible `modelValue` / `update:modelValue` +(or kebab-case `model-value` / `update:model-value`) pair, easing +migration. + +### Examples + +Examples of **incorrect** code for this rule: + +```vue + +``` + +Examples of **correct** code for this rule with the +`{ "allowVue3Compat": true }` option: + +```vue + +``` + +## Configuration + +### allowVue3Compat + +type: `boolean` + +default: `false` + +Allow `model: { prop: 'modelValue', event: 'update:modelValue' }` (or +the kebab-case `model-value` variant) which is forwards-compatible with +Vue 3's `v-model`. + +## How to use + + + +## Version + +This rule was added in vnext. + +## References + + diff --git a/src/docs/guide/usage/linter/rules/vue/return-in-computed-property.md b/src/docs/guide/usage/linter/rules/vue/return-in-computed-property.md new file mode 100644 index 00000000000..fd1761a76fd --- /dev/null +++ b/src/docs/guide/usage/linter/rules/vue/return-in-computed-property.md @@ -0,0 +1,80 @@ +--- +title: "vue/return-in-computed-property" +category: "Correctness" +version: "next" +default: false +type_aware: false +fix: "none" +--- + + + + + + + +### What it does + +Enforce that a `return` statement is present in every computed property. + +### Why is this bad? + +A Vue computed property is a getter that must produce a value. Forgetting +to return turns the value into `undefined`, which silently breaks +templates and reactive code that depend on the computed. + +### Examples + +Examples of **incorrect** code for this rule: + +```vue + +``` + +Examples of **correct** code for this rule: + +```vue + +``` + +## Configuration + +### treatUndefinedAsUnspecified + +type: `boolean` + +default: `true` + +When `true` (default), `return;` (without a value) is treated as a missing return. +Set to `false` to allow bare `return;` as if it returned a value. + +## How to use + + + +## Version + +This rule was added in vnext. + +## References + + diff --git a/src/docs/guide/usage/rule-count.data.js b/src/docs/guide/usage/rule-count.data.js index 67daf993e63..8fef6591362 100644 --- a/src/docs/guide/usage/rule-count.data.js +++ b/src/docs/guide/usage/rule-count.data.js @@ -1,5 +1,5 @@ export default { load() { - return 756; + return 784; }, };