From 7a97360d0955bf7ea3948baa107249e39a98a5fe Mon Sep 17 00:00:00 2001 From: Boshen <1430279+Boshen@users.noreply.github.com> Date: Mon, 24 Nov 2025 10:53:29 +0000 Subject: [PATCH] Release 1.30.0 --- src/docs/guide/usage/linter/generated-cli.md | 2 + .../guide/usage/linter/generated-rules.md | 10 +- .../guide/usage/linter/rules/eslint/curly.md | 8 +- .../usage/linter/rules/eslint/default-case.md | 26 +++-- .../usage/linter/rules/eslint/new-cap.md | 62 ++++++++++ .../linter/rules/eslint/no-cond-assign.md | 13 +++ .../linter/rules/eslint/no-const-assign.md | 7 +- .../linter/rules/eslint/no-else-return.md | 22 ++-- .../linter/rules/eslint/no-fallthrough.md | 29 +++++ .../rules/eslint/no-inner-declarations.md | 20 ++++ .../linter/rules/eslint/no-unsafe-finally.md | 2 +- .../linter/rules/eslint/no-unused-vars.md | 27 +++++ .../rules/eslint/operator-assignment.md | 20 +--- .../usage/linter/rules/eslint/sort-keys.md | 26 ++--- .../usage/linter/rules/jsdoc/require-param.md | 74 +++++++++++- .../linter/rules/jsdoc/require-returns.md | 44 +++++++ .../usage/linter/rules/oxc/approx-constant.md | 6 + .../oxc/bad-array-method-on-arguments.md | 10 +- .../usage/linter/rules/promise/param-names.md | 24 ++++ .../linter/rules/promise/valid-params.md | 2 + .../linter/rules/react/jsx-handler-names.md | 81 +++++++++---- .../linter/rules/react/prefer-es6-class.md | 12 ++ .../rules/react/state-in-constructor.md | 12 ++ .../consistent-generic-constructors.md | 10 ++ .../consistent-indexed-object-style.md | 9 +- .../typescript/consistent-type-definitions.md | 6 +- .../typescript/consistent-type-imports.md | 67 ++++++----- .../rules/typescript/prefer-includes.md | 109 ++++++++++++++++++ .../linter/rules/typescript/return-await.md | 24 ++++ .../linter/rules/unicorn/catch-error-name.md | 40 ++----- .../rules/unicorn/prefer-bigint-literals.md | 74 ++++++++++++ .../rules/unicorn/switch-case-braces.md | 22 ++-- .../guide/usage/linter/rules/version.data.js | 2 +- .../rules/vue/define-emits-declaration.md | 23 ++-- .../rules/vue/define-props-declaration.md | 15 ++- 35 files changed, 771 insertions(+), 169 deletions(-) create mode 100644 src/docs/guide/usage/linter/rules/typescript/prefer-includes.md create mode 100644 src/docs/guide/usage/linter/rules/unicorn/prefer-bigint-literals.md diff --git a/src/docs/guide/usage/linter/generated-cli.md b/src/docs/guide/usage/linter/generated-cli.md index a6c4422deba..3226b80fc23 100644 --- a/src/docs/guide/usage/linter/generated-cli.md +++ b/src/docs/guide/usage/linter/generated-cli.md @@ -148,6 +148,8 @@ Arguments: Disable the automatic loading of nested configuration files - **`--type-aware`** — Enable rules that require type information +- **`--type-check`** — + Enable experimental type checking (includes TypeScript compiler diagnostics) - **`-h`**, **`--help`** — Prints help information - **`-V`**, **`--version`** — diff --git a/src/docs/guide/usage/linter/generated-rules.md b/src/docs/guide/usage/linter/generated-rules.md index 3a3ffce1879..28b5661d453 100644 --- a/src/docs/guide/usage/linter/generated-rules.md +++ b/src/docs/guide/usage/linter/generated-rules.md @@ -6,7 +6,7 @@ search: false The progress of all rule implementations is tracked [here](https://github.com/oxc-project/oxc/issues/481). -- Total number of rules: 615 +- Total number of rules: 617 - Rules turned on by default: 103 **Legend for 'Fixable?' column:** @@ -345,7 +345,7 @@ code that is most likely wrong or useless. | [no-self-import](/docs/guide/usage/linter/rules/import/no-self-import.html) | import | | | | [no-unassigned-import](/docs/guide/usage/linter/rules/import/no-unassigned-import.html) | import | | | | [no-commented-out-tests](/docs/guide/usage/linter/rules/jest/no-commented-out-tests.html) | jest | | | -| [approx-constant](/docs/guide/usage/linter/rules/oxc/approx-constant.html) | oxc | | | +| [approx-constant](/docs/guide/usage/linter/rules/oxc/approx-constant.html) | oxc | | 🚧 | | [misrefactored-assign-op](/docs/guide/usage/linter/rules/oxc/misrefactored-assign-op.html) | oxc | | 🚧 | | [no-async-endpoint-handlers](/docs/guide/usage/linter/rules/oxc/no-async-endpoint-handlers.html) | oxc | | | | [always-return](/docs/guide/usage/linter/rules/promise/always-return.html) | promise | | | @@ -377,7 +377,7 @@ code that is most likely wrong or useless. | [no-required-prop-with-default](/docs/guide/usage/linter/rules/vue/no-required-prop-with-default.html) | vue | | 🚧 | | [require-default-export](/docs/guide/usage/linter/rules/vue/require-default-export.html) | vue | | | -## Pedantic (105): +## Pedantic (106): Lints which are rather strict or have occasional false positives. @@ -437,6 +437,7 @@ Lints which are rather strict or have occasional false positives. | [no-unsafe-return](/docs/guide/usage/linter/rules/typescript/no-unsafe-return.html) | typescript | | 🚧 | | [only-throw-error](/docs/guide/usage/linter/rules/typescript/only-throw-error.html) | typescript | | 🚧 | | [prefer-enum-initializers](/docs/guide/usage/linter/rules/typescript/prefer-enum-initializers.html) | typescript | | 🚧 | +| [prefer-includes](/docs/guide/usage/linter/rules/typescript/prefer-includes.html) | typescript | | 🚧 | | [prefer-promise-reject-errors](/docs/guide/usage/linter/rules/typescript/prefer-promise-reject-errors.html) | typescript | | 🚧 | | [prefer-ts-expect-error](/docs/guide/usage/linter/rules/typescript/prefer-ts-expect-error.html) | typescript | | 🛠️ | | [related-getter-setter-pairs](/docs/guide/usage/linter/rules/typescript/related-getter-setter-pairs.html) | typescript | | 🚧 | @@ -489,7 +490,7 @@ Lints which are rather strict or have occasional false positives. | [prefer-type-error](/docs/guide/usage/linter/rules/unicorn/prefer-type-error.html) | unicorn | | 🛠️ | | [require-number-to-fixed-digits-argument](/docs/guide/usage/linter/rules/unicorn/require-number-to-fixed-digits-argument.html) | unicorn | | 🛠️ | -## Style (167): +## Style (168): Code that should be written in a more idiomatic way. @@ -634,6 +635,7 @@ Code that should be written in a more idiomatic way. | [number-literal-case](/docs/guide/usage/linter/rules/unicorn/number-literal-case.html) | unicorn | | 🛠️ | | [numeric-separators-style](/docs/guide/usage/linter/rules/unicorn/numeric-separators-style.html) | unicorn | | 🛠️ | | [prefer-array-index-of](/docs/guide/usage/linter/rules/unicorn/prefer-array-index-of.html) | unicorn | | 🚧 | +| [prefer-bigint-literals](/docs/guide/usage/linter/rules/unicorn/prefer-bigint-literals.html) | unicorn | | 🛠️ | | [prefer-class-fields](/docs/guide/usage/linter/rules/unicorn/prefer-class-fields.html) | unicorn | | 🛠️💡 | | [prefer-classlist-toggle](/docs/guide/usage/linter/rules/unicorn/prefer-classlist-toggle.html) | unicorn | | 🛠️ | | [prefer-dom-node-text-content](/docs/guide/usage/linter/rules/unicorn/prefer-dom-node-text-content.html) | unicorn | | 🛠️ | diff --git a/src/docs/guide/usage/linter/rules/eslint/curly.md b/src/docs/guide/usage/linter/rules/eslint/curly.md index b593275ea17..57ddce0b5d2 100644 --- a/src/docs/guide/usage/linter/rules/eslint/curly.md +++ b/src/docs/guide/usage/linter/rules/eslint/curly.md @@ -44,8 +44,12 @@ Examples of **correct** code for this rule: ```js /* curly: ["error", "all"] */ -if (foo) foo++; -while (bar) bar--; +if (foo) { + foo++; +} +while (bar) { + bar--; +} do { foo(); } while (bar); diff --git a/src/docs/guide/usage/linter/rules/eslint/default-case.md b/src/docs/guide/usage/linter/rules/eslint/default-case.md index dc848ad44c0..caea5404131 100644 --- a/src/docs/guide/usage/linter/rules/eslint/default-case.md +++ b/src/docs/guide/usage/linter/rules/eslint/default-case.md @@ -24,14 +24,6 @@ makes the code more explicit and reduces mistakes. You may optionally include a `// no default` after the last case if there is no default case. The comment may be in any desired case, such as `// No Default`. -### Options - -First option: - -- Type: `object` -- Properties: - - `commentPattern`: `string` (default: `/^no default$/i`) - A regex pattern used to detect comments that mark the absence of a `default` case as intentional. - Example configuration: ```json @@ -70,12 +62,26 @@ switch (a) { } ``` -#### `commentPattern` +## Configuration + +This rule accepts a configuration object with the following properties: + +### commentPattern + +type: `[ + string, + null +]` + +A regex pattern used to detect comments that mark the absence +of a `default` case as intentional. + +Default value: `no default`. Examples of **incorrect** code for this rule with the `{ "commentPattern": "^skip\\sdefault" }` option: ```js -/* default-case: ["error", { "commentPattern": "^skip\\sdefault" }] */ +/* default-case: ["error", { "commentPattern": "^skip\sdefault" }] */ switch (a) { case 1: diff --git a/src/docs/guide/usage/linter/rules/eslint/new-cap.md b/src/docs/guide/usage/linter/rules/eslint/new-cap.md index abb5f4b2034..90df8ac85b5 100644 --- a/src/docs/guide/usage/linter/rules/eslint/new-cap.md +++ b/src/docs/guide/usage/linter/rules/eslint/new-cap.md @@ -325,6 +325,68 @@ Examples of **correct** code for this rule with the `{ "properties": false }` op var friend = new person.acquaintance(); ``` +## Configuration + +This rule accepts a configuration object with the following properties: + +### capIsNew + +type: `boolean` + +default: `true` + +`true` to require that all functions with names starting with an uppercase letter to be called with `new`. + +### capIsNewExceptionPattern + +type: `[ + string, + null +]` + +A regex pattern to match exceptions for functions with names starting with an uppercase letter. + +### capIsNewExceptions + +type: `string[]` + +default: `[]` + +Exceptions to ignore for functions with names starting with an uppercase letter. + +### newIsCap + +type: `boolean` + +default: `true` + +`true` to require that all constructor names start with an uppercase letter, e.g. `new Person()`. + +### newIsCapExceptionPattern + +type: `[ + string, + null +]` + +A regex pattern to match exceptions for constructor names starting with an uppercase letter. + +### newIsCapExceptions + +type: `string[]` + +default: `["Array", "Boolean", "Date", "Error", "Function", "Number", "Object", "RegExp", "String", "Symbol", "BigInt"]` + +Exceptions to ignore for constructor names starting with an uppercase letter. + +### properties + +type: `boolean` + +default: `true` + +`true` to require capitalization for object properties (e.g., `new obj.Method()`). + ## How to use To **enable** this rule in the CLI or using the config file, you can use: diff --git a/src/docs/guide/usage/linter/rules/eslint/no-cond-assign.md b/src/docs/guide/usage/linter/rules/eslint/no-cond-assign.md index 276eacac4e3..d2e4f5d8f96 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-cond-assign.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-cond-assign.md @@ -46,6 +46,19 @@ if (user.jobTitle === "manager") { } ``` +## Configuration + +This rule accepts one of the following string values: + +### `"except-parens"` + +Allow assignments in conditional expressions only if they are +enclosed in parentheses. + +### `"always"` + +Disallow all assignments in conditional expressions. + ## How to use To **enable** this rule in the CLI or using the config file, you can use: diff --git a/src/docs/guide/usage/linter/rules/eslint/no-const-assign.md b/src/docs/guide/usage/linter/rules/eslint/no-const-assign.md index 2af295137ef..b5155df3236 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-const-assign.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-const-assign.md @@ -19,8 +19,11 @@ Disallow reassigning `const` variables. ### Why is this bad? -We cannot modify variables that are declared using const keyword. -It will raise a runtime error. +We cannot modify variables that are declared using the `const` keyword, +as it will raise a runtime error. + +Note that this rule is not necessary for TypeScript +code, as TypeScript will already catch this as an error. ### Examples diff --git a/src/docs/guide/usage/linter/rules/eslint/no-else-return.md b/src/docs/guide/usage/linter/rules/eslint/no-else-return.md index 812301668b2..b389c6882c8 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-else-return.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-else-return.md @@ -37,12 +37,6 @@ following an `if` containing a return statement. As such, it will warn when it encounters an `else` following a chain of `if`s, all of them containing a `return` statement. -Options -This rule has an object option: - -- `allowElseIf`: `true` _(default)_ allows `else if` blocks after a return -- `allowElseIf`: `false` disallows `else if` blocks after a return - ### Examples #### `allowElseIf: true` @@ -142,9 +136,19 @@ function foo4() { } ``` -#### `allowElseIf: false` +## Configuration -Examples of **incorrect** code for this rule: +This rule accepts a configuration object with the following properties: + +### allowElseIf + +type: `boolean` + +default: `true` + +Whether to allow `else if` blocks after a return statement. + +Examples of **incorrect** code for this rule with `allowElseIf: false`: ```javascript function foo() { @@ -156,7 +160,7 @@ function foo() { } ``` -Examples of **correct** code for this rule: +Examples of **correct** code for this rule with `allowElseIf: false`: ```javascript function foo() { diff --git a/src/docs/guide/usage/linter/rules/eslint/no-fallthrough.md b/src/docs/guide/usage/linter/rules/eslint/no-fallthrough.md index 8df623b5009..74a38a21dc1 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-fallthrough.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-fallthrough.md @@ -184,6 +184,35 @@ switch (foo) { Note that the last case statement in these examples does not cause a warning because there is nothing to fall through into. +## Configuration + +This rule accepts a configuration object with the following properties: + +### allowEmptyCase + +type: `boolean` + +default: `false` + +Whether to allow empty case clauses to fall through. + +### commentPattern + +type: `[ + string, + null +]` + +Custom regex pattern to match fallthrough comments. + +### reportUnusedFallthroughComment + +type: `boolean` + +default: `false` + +Whether to report unused fallthrough comments. + ## How to use To **enable** this rule in the CLI or using the config file, you can use: diff --git a/src/docs/guide/usage/linter/rules/eslint/no-inner-declarations.md b/src/docs/guide/usage/linter/rules/eslint/no-inner-declarations.md index bb814c254b3..eb6b4ba77f5 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-inner-declarations.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-inner-declarations.md @@ -45,16 +45,36 @@ This rule accepts a configuration object with the following properties: ### blockScopedFunctions +type: `"allow" | "disallow"` + default: `null` Controls whether function declarations in nested blocks are allowed in strict mode (ES6+ behavior). +#### `"allow"` + +Allow function declarations in nested blocks in strict mode (ES6+ behavior). + +#### `"disallow"` + +Disallow function declarations in nested blocks regardless of strict mode. + ### config +type: `"functions" | "both"` + default: `"functions"` Determines what type of declarations to check. +#### `"functions"` + +Disallows function declarations in nested blocks. + +#### `"both"` + +Disallows function and var declarations in nested blocks. + ## How to use To **enable** this rule in the CLI or using the config file, you can use: diff --git a/src/docs/guide/usage/linter/rules/eslint/no-unsafe-finally.md b/src/docs/guide/usage/linter/rules/eslint/no-unsafe-finally.md index f253c28bfed..5b9165c8bf5 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-unsafe-finally.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-unsafe-finally.md @@ -15,7 +15,7 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Disallow control flow statements in finally blocks +Disallow control flow statements in `finally` blocks. ### Why is this bad? diff --git a/src/docs/guide/usage/linter/rules/eslint/no-unused-vars.md b/src/docs/guide/usage/linter/rules/eslint/no-unused-vars.md index 1769dcfb009..f0969482b05 100644 --- a/src/docs/guide/usage/linter/rules/eslint/no-unused-vars.md +++ b/src/docs/guide/usage/linter/rules/eslint/no-unused-vars.md @@ -187,6 +187,8 @@ This rule accepts a configuration object with the following properties: ### args +type: `"afterUsed" | "all" | "none"` + Controls how unused arguments are checked. This option has three settings: @@ -198,6 +200,20 @@ This option has three settings: 2. `all` - All named arguments must be used. 3. `none` - Do not check arguments. +#### `"afterUsed"` + +Unused positional arguments that occur before the last used argument +will not be checked, but all named arguments and all positional +arguments after the last used argument will be checked. + +#### `"all"` + +All named arguments must be used + +#### `"none"` + +Do not check arguments + ### caughtErrors type: `boolean` @@ -366,6 +382,8 @@ function foo(): typeof foo {} ### vars +type: `"all" | "local"` + Controls how usage of a variable in the global scope is checked. This option has two settings: @@ -375,6 +393,15 @@ This option has two settings: 2. `local` checks only that locally-declared variables are used but will allow global variables to be unused. +#### `"all"` + +All variables are checked for usage, including those in the global scope. + +#### `"local"` + +Checks only that locally-declared variables are used but will allow +global variables to be unused. + ## How to use To **enable** this rule in the CLI or using the config file, you can use: diff --git a/src/docs/guide/usage/linter/rules/eslint/operator-assignment.md b/src/docs/guide/usage/linter/rules/eslint/operator-assignment.md index e8c6c7b48aa..544965c746d 100644 --- a/src/docs/guide/usage/linter/rules/eslint/operator-assignment.md +++ b/src/docs/guide/usage/linter/rules/eslint/operator-assignment.md @@ -64,25 +64,15 @@ x.y = x.y / a.b; ## Configuration -This rule accepts a configuration object with the following properties: +This rule accepts one of the following string values: -### mode +### `"always"` -type: `"always" | "never"` +Requires assignment operator shorthand where possible. -default: `"always"` +### `"never"` -This rule has a single string option: - -- `always` requires assignment operator shorthand where possible -- `never` disallows assignment operator shorthand - -Example: - -```json -"eslint/operator-assignment": ["error", "always"] -"eslint/operator-assignment": ["error", "never"] -``` +Disallows assignment operator shorthand. ## How to use diff --git a/src/docs/guide/usage/linter/rules/eslint/sort-keys.md b/src/docs/guide/usage/linter/rules/eslint/sort-keys.md index d7db6ec6096..cb7762755c2 100644 --- a/src/docs/guide/usage/linter/rules/eslint/sort-keys.md +++ b/src/docs/guide/usage/linter/rules/eslint/sort-keys.md @@ -44,9 +44,17 @@ let myObj = { ## Configuration -This rule accepts a configuration object with the following properties: +### The 1st option -### allowLineSeparatedGroups +type: `"desc" | "asc"` + +Sorting order for keys. Accepts "asc" for ascending or "desc" for descending. + +### The 2nd option + +This option is an object with the following properties: + +#### allowLineSeparatedGroups type: `boolean` @@ -54,7 +62,7 @@ default: `false` When true, groups of properties separated by a blank line are sorted independently. -### caseSensitive +#### caseSensitive type: `boolean` @@ -62,7 +70,7 @@ default: `true` Whether the sort comparison is case-sensitive (A < a when true). -### minKeys +#### minKeys type: `integer` @@ -70,7 +78,7 @@ default: `2` Minimum number of properties required in an object before sorting is enforced. -### natural +#### natural type: `boolean` @@ -78,14 +86,6 @@ default: `false` Use natural sort order so that, for example, "a2" comes before "a10". -### sortOrder - -type: `"desc" | "asc"` - -default: `"asc"` - -Sorting order for keys. Accepts "asc" for ascending or "desc" for descending. - ## How to use To **enable** this rule in the CLI or using the config file, you can use: diff --git a/src/docs/guide/usage/linter/rules/jsdoc/require-param.md b/src/docs/guide/usage/linter/rules/jsdoc/require-param.md index 083887e2278..bd2a16644e9 100644 --- a/src/docs/guide/usage/linter/rules/jsdoc/require-param.md +++ b/src/docs/guide/usage/linter/rules/jsdoc/require-param.md @@ -16,7 +16,8 @@ Requires that all function parameters are documented with JSDoc `@param` tags. ### Why is this bad? -The rule is aimed at enforcing code quality and maintainability by requiring that all function parameters are documented. +The rule is aimed at enforcing code quality and maintainability by requiring +that all function parameters are documented. ### Examples @@ -34,6 +35,77 @@ Examples of **correct** code for this rule: function quux(foo) {} ``` +## Configuration + +This rule accepts a configuration object with the following properties: + +### checkConstructors + +type: `boolean` + +default: `false` + +Whether to check constructor methods. + +### checkDestructured + +type: `boolean` + +default: `true` + +Whether to check destructured parameters. + +### checkDestructuredRoots + +type: `boolean` + +default: `true` + +Whether to check destructured parameters when you have code like +`function doSomething({ a, b }) { ... }`. Because there is no named +parameter in this example, when this option is `true` you must +have a `@param` tag that corresponds to `{a, b}`. + +### checkGetters + +type: `boolean` + +default: `true` + +Whether to check getter methods. + +### checkRestProperty + +type: `boolean` + +default: `false` + +Whether to check rest properties. + +### checkSetters + +type: `boolean` + +default: `true` + +Whether to check setter methods. + +### checkTypesPattern + +type: `string` + +default: `"^(?:[oO]bject|[aA]rray|PlainObject|Generic(?:Object|Array))$"` + +Regex pattern to match types that exempt parameters from checking. + +### exemptedBy + +type: `string[]` + +default: `["inheritdoc"]` + +List of JSDoc tags that exempt functions from `@param` checking. + ## How to use To **enable** this rule in the CLI or using the config file, you can use: diff --git a/src/docs/guide/usage/linter/rules/jsdoc/require-returns.md b/src/docs/guide/usage/linter/rules/jsdoc/require-returns.md index e45f299e689..24185e64511 100644 --- a/src/docs/guide/usage/linter/rules/jsdoc/require-returns.md +++ b/src/docs/guide/usage/linter/rules/jsdoc/require-returns.md @@ -47,6 +47,50 @@ function quux() { } ``` +## Configuration + +This rule accepts a configuration object with the following properties: + +### checkConstructors + +type: `boolean` + +default: `false` + +Whether to check constructor methods. + +### checkGetters + +type: `boolean` + +default: `true` + +Whether to check getter methods. + +### exemptedBy + +type: `string[]` + +default: `["inheritdoc"]` + +Tags that exempt functions from requiring `@returns`. + +### forceRequireReturn + +type: `boolean` + +default: `false` + +Whether to require a `@returns` tag even if the function doesn't return a value. + +### forceReturnsWithAsync + +type: `boolean` + +default: `false` + +Whether to require a `@returns` tag for async functions. + ## How to use To **enable** this rule in the CLI or using the config file, you can use: diff --git a/src/docs/guide/usage/linter/rules/oxc/approx-constant.md b/src/docs/guide/usage/linter/rules/oxc/approx-constant.md index b0b069a012a..21ff5bfb4ba 100644 --- a/src/docs/guide/usage/linter/rules/oxc/approx-constant.md +++ b/src/docs/guide/usage/linter/rules/oxc/approx-constant.md @@ -8,6 +8,9 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin # oxc/approx-constant
+ +🚧 An auto-fix is still under development. +
### What it does @@ -18,6 +21,9 @@ of the constants in the `Math` object. ### Why is this bad? Approximate constants are not as accurate as the constants in the `Math` object. +Using the `Math` constants improves code readability and accuracy. +See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math +for more information. ### Examples diff --git a/src/docs/guide/usage/linter/rules/oxc/bad-array-method-on-arguments.md b/src/docs/guide/usage/linter/rules/oxc/bad-array-method-on-arguments.md index 20b32c8cc11..42a4b64fe57 100644 --- a/src/docs/guide/usage/linter/rules/oxc/bad-array-method-on-arguments.md +++ b/src/docs/guide/usage/linter/rules/oxc/bad-array-method-on-arguments.md @@ -19,9 +19,16 @@ This rule applies when an array method is called on the arguments object itself. ### Why is this bad? -The arguments object is not an array, but an array-like object. It should be converted to a real array before calling an array method. +The [arguments object](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/arguments) +is not an array, but an array-like object. It should be converted to a real array before calling an array method. Otherwise, a TypeError exception will be thrown because of the non-existent method. +Note that you probably don't need this rule if you are using exclusively +TypeScript, as it will catch these errors when typechecking. + +`arguments` usage is usually discouraged in modern JavaScript, and you should prefer using +rest parameters instead, e.g. `function sum(...args)`. + ### Examples Examples of **incorrect** code for this rule: @@ -41,6 +48,7 @@ Examples of **correct** code for this rule: function add(x, y) { return x + y; } + function sum(...args) { return args.reduce(add, 0); } diff --git a/src/docs/guide/usage/linter/rules/promise/param-names.md b/src/docs/guide/usage/linter/rules/promise/param-names.md index f9c6ca028cb..da0bfd9f2dc 100644 --- a/src/docs/guide/usage/linter/rules/promise/param-names.md +++ b/src/docs/guide/usage/linter/rules/promise/param-names.md @@ -36,6 +36,30 @@ Examples of **correct** code for this rule: new Promise(function(resolve, reject) {}); ``` +## Configuration + +This rule accepts a configuration object with the following properties: + +### rejectPattern + +type: `[ + string, + null +]` + +Regex pattern used to validate the `reject` parameter name. If provided, this pattern +is used instead of the default `^_?reject$` check. + +### resolvePattern + +type: `[ + string, + null +]` + +Regex pattern used to validate the `resolve` parameter name. If provided, this pattern +is used instead of the default `^_?resolve$` check. + ## How to use To **enable** this rule in the CLI or using the config file, you can use: diff --git a/src/docs/guide/usage/linter/rules/promise/valid-params.md b/src/docs/guide/usage/linter/rules/promise/valid-params.md index a1d9995c75b..85d609dd04f 100644 --- a/src/docs/guide/usage/linter/rules/promise/valid-params.md +++ b/src/docs/guide/usage/linter/rules/promise/valid-params.md @@ -14,6 +14,8 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin Enforces the proper number of arguments are passed to Promise functions. +This rule is generally unnecessary if using TypeScript. + ### Why is this bad? Calling a Promise function with the incorrect number of arguments can lead to unexpected diff --git a/src/docs/guide/usage/linter/rules/react/jsx-handler-names.md b/src/docs/guide/usage/linter/rules/react/jsx-handler-names.md index c63c745af9f..ad6d99a03e6 100644 --- a/src/docs/guide/usage/linter/rules/react/jsx-handler-names.md +++ b/src/docs/guide/usage/linter/rules/react/jsx-handler-names.md @@ -34,30 +34,67 @@ Examples of **correct** code for this rule: ``` -### Options +## Configuration -```json -{ - "react/jsx-handler-names": [, { - "eventHandlerPrefix": , - "eventHandlerPropPrefix": , - "checkLocalVariables": , - "checkInlineFunction": , - "ignoreComponentNames": Array - }] -} -``` +This rule accepts a configuration object with the following properties: + +### checkInlineFunctions + +type: `boolean` + +default: `false` + +Whether to check for inline functions in JSX attributes. + +### checkLocalVariables + +type: `boolean` + +default: `false` + +Whether to check for local variables in JSX attributes. + +### eventHandlerPrefixes + +type: `string` + +default: `"handle"` + +Event handler prefixes to check against. + +### eventHandlerPropPrefixes + +type: `string` + +default: `"on"` + +Event handler prop prefixes to check against. + +### eventHandlerPropRegex + +type: `[ + string, + null +]` + +Compiled regex for event handler prop prefixes. + +### eventHandlerRegex + +type: `[ + string, + null +]` + +Compiled regex for event handler prefixes. + +### ignoreComponentNames + +type: `string[]` + +default: `[]` -- `eventHandlerPrefix`: Prefix for component methods used as event handlers. - Defaults to `handle` -- `eventHandlerPropPrefix`: Prefix for props that are used as event handlers - Defaults to `on` -- `checkLocalVariables`: Determines whether event handlers stored as local variables - are checked. Defaults to `false` -- `checkInlineFunction`: Determines whether event handlers set as inline functions are - checked. Defaults to `false` -- `ignoreComponentNames`: Array of glob strings, when matched with component name, - ignores the rule on that component. Defaults to `[]` +Component names to ignore when checking for event handler prefixes. ## How to use diff --git a/src/docs/guide/usage/linter/rules/react/prefer-es6-class.md b/src/docs/guide/usage/linter/rules/react/prefer-es6-class.md index 96ebb1782aa..e2e1387243d 100644 --- a/src/docs/guide/usage/linter/rules/react/prefer-es6-class.md +++ b/src/docs/guide/usage/linter/rules/react/prefer-es6-class.md @@ -31,6 +31,18 @@ var Hello = createReactClass({ }); ``` +## Configuration + +This rule accepts one of the following string values: + +### `"always"` + +Always prefer ES6 class-style components + +### `"never"` + +Do not allow ES6 class-style + ## How to use To **enable** this rule in the CLI or using the config file, you can use: diff --git a/src/docs/guide/usage/linter/rules/react/state-in-constructor.md b/src/docs/guide/usage/linter/rules/react/state-in-constructor.md index a70e70f8b0f..7e769362cdd 100644 --- a/src/docs/guide/usage/linter/rules/react/state-in-constructor.md +++ b/src/docs/guide/usage/linter/rules/react/state-in-constructor.md @@ -81,6 +81,18 @@ class Foo extends React.Component { } ``` +## Configuration + +This rule accepts one of the following string values: + +### `"always"` + +Enforce state initialization in the constructor. + +### `"never"` + +Enforce state initialization with a class property. + ## How to use To **enable** this rule in the CLI or using the config file, you can use: diff --git a/src/docs/guide/usage/linter/rules/typescript/consistent-generic-constructors.md b/src/docs/guide/usage/linter/rules/typescript/consistent-generic-constructors.md index c43fcb04689..cafbe07c814 100644 --- a/src/docs/guide/usage/linter/rules/typescript/consistent-generic-constructors.md +++ b/src/docs/guide/usage/linter/rules/typescript/consistent-generic-constructors.md @@ -45,6 +45,8 @@ This rule accepts a configuration object with the following properties: ### option +type: `"constructor" | "type-annotation"` + default: `"constructor"` Specifies where the generic type should be specified. @@ -54,6 +56,14 @@ Possible values: - `"constructor"` (default): Type arguments that only appear on the type annotation are disallowed. - `"type-annotation"`: Type arguments that only appear on the constructor are disallowed. +#### `"constructor"` + +Type arguments that only appear on the type annotation are disallowed. + +#### `"type-annotation"` + +Type arguments that only appear on the constructor are disallowed. + ## How to use To **enable** this rule in the CLI or using the config file, you can use: diff --git a/src/docs/guide/usage/linter/rules/typescript/consistent-indexed-object-style.md b/src/docs/guide/usage/linter/rules/typescript/consistent-indexed-object-style.md index 289f43f7b5b..c18481d6368 100644 --- a/src/docs/guide/usage/linter/rules/typescript/consistent-indexed-object-style.md +++ b/src/docs/guide/usage/linter/rules/typescript/consistent-indexed-object-style.md @@ -73,15 +73,14 @@ type Foo = { ## Configuration -This rule accepts a configuration object with the following properties: +This rule accepts one of the following string values: -### preferredStyle +### `"record"` -type: `"record" | "index-signature"` +When set to `record`, enforces the use of a `Record` for indexed object types, e.g. `Record`. -default: `"record"` +### `"index-signature"` -When set to `record`, enforces the use of a `Record` for indexed object types, e.g. `Record`. When set to `index-signature`, enforces the use of indexed signature types, e.g. `{ [key: string]: unknown }`. ## How to use diff --git a/src/docs/guide/usage/linter/rules/typescript/consistent-type-definitions.md b/src/docs/guide/usage/linter/rules/typescript/consistent-type-definitions.md index 999d99c3c09..53e2524a07b 100644 --- a/src/docs/guide/usage/linter/rules/typescript/consistent-type-definitions.md +++ b/src/docs/guide/usage/linter/rules/typescript/consistent-type-definitions.md @@ -15,11 +15,11 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin ### What it does -Enforce type definitions to consistently use either interface or type. +Enforce type definitions to consistently use either `interface` or `type`. ### Why is this bad? -TypeScript provides two common ways to define an object type: interface and type. +TypeScript provides two common ways to define an object type: `interface` and `type`. The two are generally very similar, and can often be used interchangeably. Using the same type declaration style consistently helps with code readability. @@ -54,7 +54,7 @@ type: `"interface" | "type"` default: `"interface"` -Configuration option to enforce either 'interface' or 'type' for object type definitions. +Configuration option to enforce either `interface` or `type` for object type definitions. Setting to `type` enforces the use of types for object type definitions. diff --git a/src/docs/guide/usage/linter/rules/typescript/consistent-type-imports.md b/src/docs/guide/usage/linter/rules/typescript/consistent-type-imports.md index 84afc6f36a6..e2ebba577a3 100644 --- a/src/docs/guide/usage/linter/rules/typescript/consistent-type-imports.md +++ b/src/docs/guide/usage/linter/rules/typescript/consistent-type-imports.md @@ -19,7 +19,7 @@ Enforce consistent usage of type imports. ### Why is this bad? -inconsistent usage of type imports can make the code harder to read and understand. +Inconsistent usage of type imports can make the code harder to read and understand. ### Examples @@ -38,33 +38,6 @@ Examples of **correct** code for this rule: import type { Foo } from "Foo"; ``` -### Options - -```json -{ - "typescript/consistent-type-imports": [ - "error", - { - "prefer": "type-imports", - "fixStyle": "separate-type-imports", - "disallowTypeAnnotations": true - } - ] -} -``` - -- `prefer`: Control whether to enforce type imports or value imports - - `"type-imports"` (default): Will enforce that you always use `import type Foo from '...'` except referenced by metadata of decorators - - `"no-type-imports"`: Will enforce that you always use `import Foo from '...'` - -- `fixStyle`: Determines how type imports are added when auto-fixing - - `"separate-type-imports"` (default): Will add the type keyword after the import keyword `import type { A } from '...'` - - `"inline-type-imports"`: Will inline the type keyword `import { type A } from '...'` (only available in TypeScript 4.5+) - -- `disallowTypeAnnotations`: Disallow using `import()` in type annotations - - `true` (default): Disallows using `import()` in type annotations like `type T = import('foo')` - - `false`: Allows `import()` type annotations - #### Examples with `"prefer": "type-imports"` (default) Examples of **incorrect** code: @@ -121,6 +94,44 @@ When set to `false`, allows `import()` type annotations: type T = import("foo").Bar; ``` +## Configuration + +This rule accepts a configuration object with the following properties: + +### disallowTypeAnnotations + +type: `boolean` + +Disallow using `import()` in type annotations, like `type T = import('foo')` + +### fixStyle + +type: `"separate-type-imports" | "inline-type-imports"` + +Control how type imports are added when auto-fixing. + +#### `"separate-type-imports"` + +Will add the type keyword after the import keyword `import type { A } from '...'` + +#### `"inline-type-imports"` + +Will inline the type keyword `import { type A } from '...'` (only available in TypeScript 4.5+) + +### prefer + +type: `"type-imports" | "no-type-imports"` + +Control whether to enforce type imports or value imports. + +#### `"type-imports"` + +Will enforce that you always use `import type Foo from '...'` except referenced by metadata of decorators. + +#### `"no-type-imports"` + +Will enforce that you always use `import Foo from '...'` + ## How to use To **enable** this rule in the CLI or using the config file, you can use: diff --git a/src/docs/guide/usage/linter/rules/typescript/prefer-includes.md b/src/docs/guide/usage/linter/rules/typescript/prefer-includes.md new file mode 100644 index 00000000000..42c9d8f00d9 --- /dev/null +++ b/src/docs/guide/usage/linter/rules/typescript/prefer-includes.md @@ -0,0 +1,109 @@ + + + + +# typescript/prefer-includes + +
+ +💭 This rule requires type information. + + +🚧 An auto-fix is still under development. + +
+ +### What it does + +Enforce using `.includes()` instead of `.indexOf() !== -1` or `/regex/.test()`. + +### Why is this bad? + +`.includes()` is more readable and expressive than checking `.indexOf() !== -1`. +It clearly communicates the intent to check for the presence of a value. +Additionally, for simple string searches, `.includes()` is often preferred over +regex `.test()` for better performance and clarity. + +### Examples + +Examples of **incorrect** code for this rule: + +```ts +// Using indexOf +const str = "hello world"; +if (str.indexOf("world") !== -1) { + console.log("found"); +} + +if (str.indexOf("world") != -1) { + console.log("found"); +} + +if (str.indexOf("world") > -1) { + console.log("found"); +} + +// Using regex test for simple strings +if (/world/.test(str)) { + console.log("found"); +} + +// Arrays +const arr = [1, 2, 3]; +if (arr.indexOf(2) !== -1) { + console.log("found"); +} +``` + +Examples of **correct** code for this rule: + +```ts +// Using includes for strings +const str = "hello world"; +if (str.includes("world")) { + console.log("found"); +} + +// Using includes for arrays +const arr = [1, 2, 3]; +if (arr.includes(2)) { + console.log("found"); +} + +// Complex regex patterns are allowed +if (/wo+rld/.test(str)) { + console.log("found"); +} + +// Regex with flags +if (/world/i.test(str)) { + console.log("found"); +} +``` + +## How to use + +To **enable** this rule in the CLI or using the config file, you can use: + +::: code-group + +```bash [CLI] +oxlint --type-aware --deny typescript/prefer-includes +``` + +```json [Config (.oxlintrc.json)] +{ + "rules": { + "typescript/prefer-includes": "error" + } +} +``` + +::: + +## References + +- Rule Source diff --git a/src/docs/guide/usage/linter/rules/typescript/return-await.md b/src/docs/guide/usage/linter/rules/typescript/return-await.md index 8cfd526148c..a525ad6b7bb 100644 --- a/src/docs/guide/usage/linter/rules/typescript/return-await.md +++ b/src/docs/guide/usage/linter/rules/typescript/return-await.md @@ -80,6 +80,30 @@ async function multipleOperations() { } ``` +## Configuration + +This rule accepts one of the following string values: + +### `"in-try-catch"` + +Require `await` when returning Promises inside try/catch/finally blocks. +This ensures proper error handling and stack traces. + +### `"always"` + +Require `await` before returning Promises in all cases. +Example: `return await Promise.resolve()` is required. + +### `"error-handling-correctness-only"` + +Require `await` only when it affects error handling correctness. +Only flags cases where omitting await would change error handling behavior. + +### `"never"` + +Disallow `await` before returning Promises in all cases. +Example: `return Promise.resolve()` is required (no await). + ## How to use To **enable** this rule in the CLI or using the config file, you can use: diff --git a/src/docs/guide/usage/linter/rules/unicorn/catch-error-name.md b/src/docs/guide/usage/linter/rules/unicorn/catch-error-name.md index 43988389bde..faacce7bc69 100644 --- a/src/docs/guide/usage/linter/rules/unicorn/catch-error-name.md +++ b/src/docs/guide/usage/linter/rules/unicorn/catch-error-name.md @@ -61,43 +61,25 @@ promise.catch(error => {}); promise.then(undefined, error => {}); ``` -### Options +## Configuration -#### name +This rule accepts a configuration object with the following properties: -`{ type: string, default: "error" }` +### ignore -The name to use for error variables in `catch` blocks. You can customize it -to something other than `'error'` (e.g., `'exception'`). - -Example: - -```json -"unicorn/catch-error-name": [ - "error", - { "name": "exception" } -] -``` - -#### ignore - -`{ type: Array, default: [] }` +type: `string[]` A list of patterns to ignore when checking `catch` variable names. The pattern can be a string or regular expression. -Example: +### name -```json -"unicorn/catch-error-name": [ - "error", - { - "ignore": [ - "^error\\d*$" - ] - } -] -``` +type: `string` + +default: `"error"` + +The name to use for error variables in `catch` blocks. You can customize it +to something other than `'error'` (e.g., `'exception'`). ## How to use diff --git a/src/docs/guide/usage/linter/rules/unicorn/prefer-bigint-literals.md b/src/docs/guide/usage/linter/rules/unicorn/prefer-bigint-literals.md new file mode 100644 index 00000000000..3592d21157b --- /dev/null +++ b/src/docs/guide/usage/linter/rules/unicorn/prefer-bigint-literals.md @@ -0,0 +1,74 @@ + + + + +# unicorn/prefer-bigint-literals + +
+ +🛠️ An auto-fix is available for this rule. + +
+ +### What it does + +Requires using BigInt literals (e.g. `123n`) instead of calling the `BigInt()` constructor +with literal arguments such as numbers or numeric strings + +### Why is this bad? + +Using `BigInt(…)` with literal values is unnecessarily verbose and less idiomatic than using +a BigInt literal. + +### Examples + +Examples of **incorrect** code for this rule: + +```js +BigInt(0); +BigInt(123); +BigInt(0xFF); +BigInt(1e3); +BigInt("42"); +BigInt("0x10"); +``` + +Examples of **correct** code for this rule: + +```js +0n; +123n; +0xFFn; +1000n; +// Non-integer, dynamic, or non-literal input: +BigInt(x); +BigInt("not-a-number"); +BigInt("1.23"); +``` + +## How to use + +To **enable** this rule in the CLI or using the config file, you can use: + +::: code-group + +```bash [CLI] +oxlint --deny unicorn/prefer-bigint-literals +``` + +```json [Config (.oxlintrc.json)] +{ + "rules": { + "unicorn/prefer-bigint-literals": "error" + } +} +``` + +::: + +## References + +- Rule Source diff --git a/src/docs/guide/usage/linter/rules/unicorn/switch-case-braces.md b/src/docs/guide/usage/linter/rules/unicorn/switch-case-braces.md index d12c4014d30..09ec4bf53d6 100644 --- a/src/docs/guide/usage/linter/rules/unicorn/switch-case-braces.md +++ b/src/docs/guide/usage/linter/rules/unicorn/switch-case-braces.md @@ -48,21 +48,23 @@ switch (num) { } ``` -### Options +Example config: -`{ type: "always" | "avoid", default: "always" }` +```json +"unicorn/switch-case-braces": ["error", "avoid"] +``` -- `"always"` - Always report when clause is not a `BlockStatement`. +## Configuration -- `"avoid"` - Allows braces only when needed for scoping (e.g., variable or function declarations). +This rule accepts one of the following string values: -Example: +### `"always"` -```json -"unicorn/switch-case-braces": ["error", "avoid"] -``` +Always require braces in case clauses (except empty cases). + +### `"avoid"` + +Allow braces only when needed for scoping (e.g., variable or function declarations). ## How to use diff --git a/src/docs/guide/usage/linter/rules/version.data.js b/src/docs/guide/usage/linter/rules/version.data.js index 4fbd39daa5a..b07deb2a368 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 "c023ba67e07283bad3a43ef9bcc0336c94aa42ae"; + return "2c7808feee1f268881188e3eb7583d2613421dc6"; }, }; diff --git a/src/docs/guide/usage/linter/rules/vue/define-emits-declaration.md b/src/docs/guide/usage/linter/rules/vue/define-emits-declaration.md index 8a774ba1fe0..f219b97be59 100644 --- a/src/docs/guide/usage/linter/rules/vue/define-emits-declaration.md +++ b/src/docs/guide/usage/linter/rules/vue/define-emits-declaration.md @@ -85,15 +85,24 @@ const emit2 = defineEmits({ ``` -### Options +## Configuration -``` -"vue/define-emits-declaration": ["error", "type-based" | "type-literal" | "runtime"] -``` +This rule accepts one of the following string values: + +### `"type-based"` + +Enforces the use of a named TypeScript type or interface as the +argument to `defineEmits`, e.g. `defineEmits()`. + +### `"type-literal"` + +Enforces the use of an inline type literal as the argument to +`defineEmits`, e.g. `defineEmits<{ (event: string): void }>()`. + +### `"runtime"` -- `type-based` (default): Enforce type-based declaration -- `type-literal`: Enforce type-literal declaration -- `runtime`: Enforce runtime declaration +Enforces the use of runtime declaration, where emits are declared +using an array or object, e.g. `defineEmits(['event1', 'event2'])`. ## How to use diff --git a/src/docs/guide/usage/linter/rules/vue/define-props-declaration.md b/src/docs/guide/usage/linter/rules/vue/define-props-declaration.md index 2127056d1df..b6ef1ebbe43 100644 --- a/src/docs/guide/usage/linter/rules/vue/define-props-declaration.md +++ b/src/docs/guide/usage/linter/rules/vue/define-props-declaration.md @@ -53,14 +53,17 @@ const props = defineProps({ ``` -### Options +## Configuration -``` -"vue/define-props-declaration": ["error", "type-based" | "runtime"] -``` +This rule accepts one of the following string values: + +### `"type-based"` + +Enforce type-based declaration. + +### `"runtime"` -- `type-based` (default) enforces type-based declaration -- `runtime` enforces runtime declaration +Enforce runtime declaration. ## How to use