ℹNesting promises can lead to harder-to-read code because it creates multiple levels of indentation and makes the flow of asynchronous operations less clear.
ℹConsider refactoring the code to use promise chaining (foo.then().then()) instead of nesting.
ℹThis rule belongs to the nursery group, which means it is not yet stable and may change in the future. Visit https://biomejs.dev/linter/#nursery for more information.
ℹNesting promises can lead to harder-to-read code because it creates multiple levels of indentation and makes the flow of asynchronous operations less clear.
ℹConsider refactoring the code to use promise chaining (foo.then().then()) instead of nesting.
ℹThis rule belongs to the nursery group, which means it is not yet stable and may change in the future. Visit https://biomejs.dev/linter/#nursery for more information.
ℹNesting promises can lead to harder-to-read code because it creates multiple levels of indentation and makes the flow of asynchronous operations less clear.
ℹConsider refactoring the code to use promise chaining (foo.then().then()) instead of nesting.
ℹThis rule belongs to the nursery group, which means it is not yet stable and may change in the future. Visit https://biomejs.dev/linter/#nursery for more information.
+
+### Valid
+
+```js
+// Simple returns
+doThing().then(function() { return 4 })
+doThing().then(() => 4)
+```
+
+```js
+// Chained promises (no nesting)
+doThing()
+ .then(a => getB(a))
+ .then(b => getC(b))
+```
+
+```js
+// Nested but references outer scope variable 'a'
+doThing()
+ .then(a => getB(a)
+ .then(b => getC(a, b))
+ )
+```
+
+```js
+// Promise.resolve/all are fine
+doThing().then(function() { return Promise.all([a,b,c]) })
+doThing().then(() => Promise.resolve(4))
+```
+
+## Related links
+
+- [Disable a rule](/linter/#disable-a-rule)
+- [Configure the code fix](/linter#configure-the-code-fix)
+- [Rule options](/linter/#rule-options)
+- [Source Code](https://github.com/biomejs/biome/blob/main/crates/biome_js_analyze/src/lint/nursery/no_nested_promises.rs)
+- [Test Cases](https://github.com/biomejs/biome/blob/main/crates/biome_js_analyze/tests/specs/nursery/noNestedPromises)
+
+
+
+
diff --git a/src/content/docs/linter/rules/no-positive-tabindex.mdx b/src/content/docs/linter/rules/no-positive-tabindex.mdx
index 6b5895334..6f45d4965 100644
--- a/src/content/docs/linter/rules/no-positive-tabindex.mdx
+++ b/src/content/docs/linter/rules/no-positive-tabindex.mdx
@@ -48,19 +48,19 @@ Avoid positive `tabIndex` property values to synchronize the flow of the page wi
ℹElements with a positive tabIndex override natural page content order. This causes elements without a positive tab index to come last when navigating using a keyboard.
ℹUse only 0 and -1 as tabIndex values. Avoid using tabIndex values greater than 0 and CSS properties that can change the order of focusable HTML elements.
ℹUnsafe fix: Replace the tableIndex prop value with 0.
ℹElements with a positive tabIndex override natural page content order. This causes elements without a positive tab index to come last when navigating using a keyboard.
ℹUse only 0 and -1 as tabIndex values. Avoid using tabIndex values greater than 0 and CSS properties that can change the order of focusable HTML elements.
ℹUnsafe fix: Replace the tabIndex prop value with 0.
ℹElements with a positive tabIndex override natural page content order. This causes elements without a positive tab index to come last when navigating using a keyboard.
ℹUse only 0 and -1 as tabIndex values. Avoid using tabIndex values greater than 0 and CSS properties that can change the order of focusable HTML elements.
ℹUnsafe fix: Replace the tableIndex prop value with 0.
ℹElements with a positive tabIndex override natural page content order. This causes elements without a positive tab index to come last when navigating using a keyboard.
ℹUse only 0 and -1 as tabIndex values. Avoid using tabIndex values greater than 0 and CSS properties that can change the order of focusable HTML elements.
ℹUnsafe fix: Replace the tabIndex prop value with 0.
ℹElements with a positive tabIndex override natural page content order. This causes elements without a positive tab index to come last when navigating using a keyboard.
ℹUse only 0 and -1 as tabIndex values. Avoid using tabIndex values greater than 0 and CSS properties that can change the order of focusable HTML elements.
ℹUnsafe fix: Replace the tableIndex prop value with 0.
ℹElements with a positive tabIndex override natural page content order. This causes elements without a positive tab index to come last when navigating using a keyboard.
ℹUse only 0 and -1 as tabIndex values. Avoid using tabIndex values greater than 0 and CSS properties that can change the order of focusable HTML elements.
ℹUnsafe fix: Replace the tabIndex prop value with 0.
### Valid
diff --git a/src/content/docs/linter/rules/no-redundant-default-export.mdx b/src/content/docs/linter/rules/no-redundant-default-export.mdx
new file mode 100644
index 000000000..cc71ea86e
--- /dev/null
+++ b/src/content/docs/linter/rules/no-redundant-default-export.mdx
@@ -0,0 +1,67 @@
+---
+# Don't modify this file manually. This file is auto generated from source, and you will lose your changes next time the website is built.
+# Head to the `biomejs/biome` repository, and modify the source code in there.
+
+title: noRedundantDefaultExport
+description: Learn more about noRedundantDefaultExport
+---
+import { Tabs, TabItem } from '@astrojs/starlight/components';
+
+
+
+:::caution
+This rule is part of the [nursery](/linter/#nursery) group. This means that it is experimental and the behavior can change at any time.
+:::
+## Summary
+- Rule available since: `v2.3.14`
+- Diagnostic Category: [`lint/nursery/noRedundantDefaultExport`](/reference/diagnostics#diagnostic-category)
+- This rule doesn't have a fix.
+- The default severity of this rule is [**warning**](/reference/diagnostics#warning).
+## How to configure
+```json title="biome.json"
+{
+ "linter": {
+ "rules": {
+ "nursery": {
+ "noRedundantDefaultExport": "error"
+ }
+ }
+ }
+}
+
+```
+## Description
+Checks if a default export exports the same symbol as a named export.
+
+This rule warns when a `default` export references the same identifier as a named export.
+Re-exports are out of scope.
+
+## Examples
+
+### Invalid
+
+```js
+export const foo = 42;
+export default foo;
+```
+
+
ℹExporting the same identifier as both a named export and a default export is redundant.
ℹRemove either the default export or the named export to avoid redundancy.
ℹThis rule belongs to the nursery group, which means it is not yet stable and may change in the future. Visit https://biomejs.dev/linter/#nursery for more information.
```ts
// Another header comment
diff --git a/src/content/docs/linter/rules/no-useless-return.mdx b/src/content/docs/linter/rules/no-useless-return.mdx
new file mode 100644
index 000000000..6e32ad834
--- /dev/null
+++ b/src/content/docs/linter/rules/no-useless-return.mdx
@@ -0,0 +1,110 @@
+---
+# Don't modify this file manually. This file is auto generated from source, and you will lose your changes next time the website is built.
+# Head to the `biomejs/biome` repository, and modify the source code in there.
+
+title: noUselessReturn
+description: Learn more about noUselessReturn
+---
+import { Tabs, TabItem } from '@astrojs/starlight/components';
+
+
+
+:::caution
+This rule is part of the [nursery](/linter/#nursery) group. This means that it is experimental and the behavior can change at any time.
+:::
+## Summary
+- Rule available since: `v2.3.15`
+- Diagnostic Category: [`lint/nursery/noUselessReturn`](/reference/diagnostics#diagnostic-category)
+- This rule has a [**safe**](/linter/#safe-fixes) fix.
+- The default severity of this rule is [**information**](/reference/diagnostics#information).
+- Sources:
+ - Inspired from [`no-useless-return`](https://eslint.org/docs/latest/rules/no-useless-return)
+
+## How to configure
+```json title="biome.json"
+{
+ "linter": {
+ "rules": {
+ "nursery": {
+ "noUselessReturn": "error"
+ }
+ }
+ }
+}
+
+```
+## Description
+Disallow redundant return statements.
+
+A `return;` statement with nothing after it is redundant when it is the
+last reachable statement in a function body. Removing it does not change
+the function's behavior, as execution naturally falls through to the end.
+
+## Examples
+
+### Invalid
+
+```js
+function foo() {
+ return;
+}
+```
+
+
ℹRemoving this statement does not change the control flow of the function.
ℹThis rule belongs to the nursery group, which means it is not yet stable and may change in the future. Visit https://biomejs.dev/linter/#nursery for more information.
ℹSafe fix: Remove the unnecessary return statement.
ℹRemoving this statement does not change the control flow of the function.
ℹThis rule belongs to the nursery group, which means it is not yet stable and may change in the future. Visit https://biomejs.dev/linter/#nursery for more information.
ℹSafe fix: Remove the unnecessary return statement.
ℹRemoving this statement does not change the control flow of the function.
ℹThis rule belongs to the nursery group, which means it is not yet stable and may change in the future. Visit https://biomejs.dev/linter/#nursery for more information.
ℹSafe fix: Remove the unnecessary return statement.
+
+### Valid
+
+```js
+function foo() {
+ return 5;
+}
+```
+
+```js
+function foo() {
+ if (condition) {
+ return;
+ }
+ bar();
+}
+```
+
+```js
+function foo() {
+ for (const x of xs) {
+ return;
+ }
+}
+```
+
+## Related links
+
+- [Disable a rule](/linter/#disable-a-rule)
+- [Configure the code fix](/linter#configure-the-code-fix)
+- [Rule options](/linter/#rule-options)
+- [Source Code](https://github.com/biomejs/biome/blob/main/crates/biome_js_analyze/src/lint/nursery/no_useless_return.rs)
+- [Test Cases](https://github.com/biomejs/biome/blob/main/crates/biome_js_analyze/tests/specs/nursery/noUselessReturn)
+
+
+
+
diff --git a/src/content/docs/linter/rules/no-vue-arrow-func-in-watch.mdx b/src/content/docs/linter/rules/no-vue-arrow-func-in-watch.mdx
index 757c1ffa2..dcd7b142b 100644
--- a/src/content/docs/linter/rules/no-vue-arrow-func-in-watch.mdx
+++ b/src/content/docs/linter/rules/no-vue-arrow-func-in-watch.mdx
@@ -9,13 +9,11 @@ import { Tabs, TabItem } from '@astrojs/starlight/components';
-:::note
-This rule has been implemented but not released yet. It will be available in the next release.
-:::
:::caution
This rule is part of the [nursery](/linter/#nursery) group. This means that it is experimental and the behavior can change at any time.
:::
## Summary
+- Rule available since: `v2.3.14`
- Diagnostic Category: [`lint/nursery/noVueArrowFuncInWatch`](/reference/diagnostics#diagnostic-category)
- This rule has an [**unsafe**](/linter/#unsafe-fixes) fix.
- The default severity of this rule is [**information**](/reference/diagnostics#information).
diff --git a/src/content/docs/linter/rules/use-arrow-function.mdx b/src/content/docs/linter/rules/use-arrow-function.mdx
index 88a313d08..7bc1ba91a 100644
--- a/src/content/docs/linter/rules/use-arrow-function.mdx
+++ b/src/content/docs/linter/rules/use-arrow-function.mdx
@@ -40,6 +40,8 @@ with an important distinction:
This rule proposes turning all function expressions that are not generators (`function*`) and don't use `this` into arrow functions.
+This rule does not modify top-level function declarations ([discuss here](https://github.com/biomejs/biome/discussions/7108)).
+
## Examples
### Invalid
diff --git a/src/content/docs/linter/rules/use-await.mdx b/src/content/docs/linter/rules/use-await.mdx
index e6f60487b..6ae55502d 100644
--- a/src/content/docs/linter/rules/use-await.mdx
+++ b/src/content/docs/linter/rules/use-await.mdx
@@ -70,6 +70,11 @@ function processData() {
// Nor does it warn about empty `async` functions
async function noop() { }
+
+// Async generators that use `yield*` with an async iterable
+async function* delegateToAsyncIterable() {
+ yield* otherAsyncIterable();
+}
```
## Related links
diff --git a/src/content/docs/linter/rules/use-consistent-method-signatures.mdx b/src/content/docs/linter/rules/use-consistent-method-signatures.mdx
new file mode 100644
index 000000000..cf860f154
--- /dev/null
+++ b/src/content/docs/linter/rules/use-consistent-method-signatures.mdx
@@ -0,0 +1,236 @@
+---
+# Don't modify this file manually. This file is auto generated from source, and you will lose your changes next time the website is built.
+# Head to the `biomejs/biome` repository, and modify the source code in there.
+
+title: useConsistentMethodSignatures
+description: Learn more about useConsistentMethodSignatures
+---
+import { Tabs, TabItem } from '@astrojs/starlight/components';
+
+
+
+:::caution
+This rule is part of the [nursery](/linter/#nursery) group. This means that it is experimental and the behavior can change at any time.
+:::
+## Summary
+- Rule available since: `v2.3.14`
+- Diagnostic Category: [`lint/nursery/useConsistentMethodSignatures`](/reference/diagnostics#diagnostic-category)
+- This rule doesn't have a fix.
+- The default severity of this rule is [**information**](/reference/diagnostics#information).
+- Sources:
+ - Same as [`@typescript-eslint/method-signature-style`](https://typescript-eslint.io/rules/method-signature-style)
+
+## How to configure
+```json title="biome.json"
+{
+ "linter": {
+ "rules": {
+ "nursery": {
+ "useConsistentMethodSignatures": "error"
+ }
+ }
+ }
+}
+
+```
+## Description
+Enforce consistent use of either method signatures or function properties within interfaces and type aliases.
+
+TypeScript provides 2 different ways to declare methods within interfaces and object types:
+
+```ts
+interface Example {
+ // method shorthand syntax
+ methodFunc(arg: string): void;
+
+ // regular property with function type
+ prop: (arg: string) => void;
+}
+
+// These forms correspond to the analogous JS object literal patterns:
+const obj = {
+ methodFunc(arg) {},
+ prop: (arg) => {},
+} satisfies Example;
+```
+
+While mostly a matter of stylistic consistency, the two gain subtle differences in behavior when the
+[`strictFunctionTypes`](https://www.typescriptlang.org/tsconfig/#strictFunctionTypes) compiler option is enabled.
+More specifically, its stricter contravariant checks will **only** apply to functions written in _property_ syntax —
+ones written as methods will remain with the weaker bivariant type checks.
+
+
+ What's the difference?
+To illustrate the differences between method bivariance and contravariance, consider the following snippet of code:
+
+```ts
+interface Emitter {
+ methodFunc(arg: Event): void;
+ propFunc: (arg: Event) => void;
+}
+
+interface SpecialEvent extends Event {
+ isBirthday: boolean;
+}
+
+interface SpecialEmitter extends Emitter {
+ methodFunc(arg: SpecialEvent): void; // OK
+ propFunc: (arg: SpecialEvent) => void; // Error under `strictFunctionTypes`
+}
+```
+
+In the above example, `SpecialEmitter.methodFunc` is compatible with `Emitter.methodFunc` under _bivariant_[^1] checks,
+as `SpecialEvent` is assignable to `Event` (i.e. all `SpecialEvent`s are guaranteed to be valid `Event`s).
+On the other hand, the strict _contravariant_ checks for function properties produce errors on `propFunc` as the reverse is not guaranteed —
+`Event` is not assignable to `SpecialEvent` (i.e. not all `Event`s are guaranteed to be valid `SpecialEvent`s).
+
+The full rationale for this behavior can be found in the [TypeScript handbook](https://www.typescriptlang.org/docs/handbook/type-compatibility.html#function-parameter-bivariance).
+
+[^1]: From a purely type-theoretical perspective, bivariance technically refers to a type being _both_ covariant _and_ contravariant at once
+(`A` ⊆ `B` implies `T` ≣ `T`).
+In practice, this is only true for pathological types like `type T = number`,
+and so is often used to refer to a type being either covariant _or_ contravariant (which simply requires `T` and `T` to have some non-zero amount of overlap).
+
+
+To avoid inconsistent type assignability issues and enforce stylistic consistency, this rule attempts to
+ensure either method- or property-style declarations are used consistently across a given codebase.
+
+:::info
+Without `strictFunctionTypes` enabled, method signatures and function properties become **functionally identical**.
+In this case, which option to use simply becomes a matter of personal preference.
+:::
+
+## Examples
+
+### Invalid
+
+```ts
+interface Example {
+ methodFunc(arg: string): number;
+}
+```
+
+
ℹConsistently using a single style of method signatures helps improve readability and consistency.
ℹProperty-style function declarations also allow for stricter type checking when the strictFunctionTypes compiler option is enabled.
ℹIf this isn't what you want, consider changing the style option in the rule's settings.
ℹThis rule is still being actively worked on, so it may be missing features or have rough edges. Visit https://github.com/biomejs/biome/issues/8780 for more information or to report possible bugs.
ℹThis rule belongs to the nursery group, which means it is not yet stable and may change in the future. Visit https://biomejs.dev/linter/#nursery for more information.
ℹConsistently using a single style of method signatures helps improve readability and consistency.
ℹProperty-style function declarations also allow for stricter type checking when the strictFunctionTypes compiler option is enabled.
ℹIf this isn't what you want, consider changing the style option in the rule's settings.
ℹThis rule is still being actively worked on, so it may be missing features or have rough edges. Visit https://github.com/biomejs/biome/issues/8780 for more information or to report possible bugs.
ℹThis rule belongs to the nursery group, which means it is not yet stable and may change in the future. Visit https://biomejs.dev/linter/#nursery for more information.
ℹConsistently using a single style of method signatures helps improve readability and consistency.
ℹProperty-style function declarations also allow for stricter type checking when the strictFunctionTypes compiler option is enabled.
ℹIf this isn't what you want, consider changing the style option in the rule's settings.
ℹThis rule is still being actively worked on, so it may be missing features or have rough edges. Visit https://github.com/biomejs/biome/issues/8780 for more information or to report possible bugs.
ℹThis rule belongs to the nursery group, which means it is not yet stable and may change in the future. Visit https://biomejs.dev/linter/#nursery for more information.
ℹConsistently using a single style of method signatures helps improve readability and consistency.
ℹProperty-style function declarations also allow for stricter type checking when the strictFunctionTypes compiler option is enabled.
ℹIf this isn't what you want, consider changing the style option in the rule's settings.
ℹThis rule is still being actively worked on, so it may be missing features or have rough edges. Visit https://github.com/biomejs/biome/issues/8780 for more information or to report possible bugs.
ℹThis rule belongs to the nursery group, which means it is not yet stable and may change in the future. Visit https://biomejs.dev/linter/#nursery for more information.
ℹConsistently using a single style of method signatures helps improve readability and consistency.
ℹIf this isn't what you want, consider changing the style option in the rule's settings.
ℹThis rule is still being actively worked on, so it may be missing features or have rough edges. Visit https://github.com/biomejs/biome/issues/8780 for more information or to report possible bugs.
ℹThis rule belongs to the nursery group, which means it is not yet stable and may change in the future. Visit https://biomejs.dev/linter/#nursery for more information.
ℹConsistently using a single style of method signatures helps improve readability and consistency.
ℹIf this isn't what you want, consider changing the style option in the rule's settings.
ℹThis rule is still being actively worked on, so it may be missing features or have rough edges. Visit https://github.com/biomejs/biome/issues/8780 for more information or to report possible bugs.
ℹThis rule belongs to the nursery group, which means it is not yet stable and may change in the future. Visit https://biomejs.dev/linter/#nursery for more information.
+
+```ts
+type OK = {
+ flubber(arg: number): number;
+}
+```
+
+[^2]: Chosen to allow stricter type checks under the aforementioned `strictFunctionTypes`.
+
+## Related links
+
+- [Disable a rule](/linter/#disable-a-rule)
+- [Configure the code fix](/linter#configure-the-code-fix)
+- [Rule options](/linter/#rule-options)
+- [Source Code](https://github.com/biomejs/biome/blob/main/crates/biome_js_analyze/src/lint/nursery/use_consistent_method_signatures.rs)
+- [Test Cases](https://github.com/biomejs/biome/blob/main/crates/biome_js_analyze/tests/specs/nursery/useConsistentMethodSignatures)
+
+
+
+
diff --git a/src/content/docs/linter/rules/use-consistent-type-definitions.mdx b/src/content/docs/linter/rules/use-consistent-type-definitions.mdx
index 8dec89c63..f6d2e79ec 100644
--- a/src/content/docs/linter/rules/use-consistent-type-definitions.mdx
+++ b/src/content/docs/linter/rules/use-consistent-type-definitions.mdx
@@ -40,6 +40,9 @@ This rule enforces consistent usage of either `interface` or `type` for object t
Consistent type definition styles, aside from improving code readability, help minimize cognitive load when developers
switch between different codebases or within a large codebase.
+Empty object type declarations will be left as-is and will not be converted to interfaces,
+as it will conflict with the `noEmptyInterface` rule.
+
## Example
### Invalid
@@ -59,6 +62,10 @@ interface Point {
}
```
+```ts
+type AnyObject = {};
+```
+
## Options
The following options are available
diff --git a/src/content/docs/linter/rules/use-exhaustive-dependencies.mdx b/src/content/docs/linter/rules/use-exhaustive-dependencies.mdx
index 222ad7b5b..79cd175b6 100644
--- a/src/content/docs/linter/rules/use-exhaustive-dependencies.mdx
+++ b/src/content/docs/linter/rules/use-exhaustive-dependencies.mdx
@@ -197,6 +197,17 @@ function component() {
ℹReact relies on hook dependencies to determine when to re-compute Effects. Failing to specify dependencies can result in Effects not updating correctly when state changes. These "stale closures" are a common source of surprising bugs.
ℹEither include it or remove the dependency array.
ℹUnsafe fix: Add the missing dependency to the list.
ℹReact relies on hook dependencies to determine when to re-compute Effects. Failing to specify dependencies can result in Effects not updating correctly when state changes. These "stale closures" are a common source of surprising bugs.
ℹEither include it or remove the dependency array.
ℹUnsafe fix: Add the missing dependency to the list.
+
### Valid
```js
diff --git a/src/content/docs/linter/rules/use-global-this.mdx b/src/content/docs/linter/rules/use-global-this.mdx
new file mode 100644
index 000000000..a4bcd22c2
--- /dev/null
+++ b/src/content/docs/linter/rules/use-global-this.mdx
@@ -0,0 +1,93 @@
+---
+# Don't modify this file manually. This file is auto generated from source, and you will lose your changes next time the website is built.
+# Head to the `biomejs/biome` repository, and modify the source code in there.
+
+title: useGlobalThis
+description: Learn more about useGlobalThis
+---
+import { Tabs, TabItem } from '@astrojs/starlight/components';
+
+
+
+:::caution
+This rule is part of the [nursery](/linter/#nursery) group. This means that it is experimental and the behavior can change at any time.
+:::
+## Summary
+- Rule available since: `v2.3.14`
+- Diagnostic Category: [`lint/nursery/useGlobalThis`](/reference/diagnostics#diagnostic-category)
+- This rule doesn't have a fix.
+- The default severity of this rule is [**warning**](/reference/diagnostics#warning).
+- Sources:
+ - Same as [`unicorn/prefer-global-this`](https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/docs/rules/prefer-global-this.md)
+
+## How to configure
+```json title="biome.json"
+{
+ "linter": {
+ "rules": {
+ "nursery": {
+ "useGlobalThis": "error"
+ }
+ }
+ }
+}
+
+```
+## Description
+Enforce the use of `globalThis` over `window`, `self`, and `global`.
+
+`globalThis` is a standard way to access the global object across platforms such as browsers, Web Workers, Node.js and so on, and using it can make your code portable.
+
+However, there are several exceptions that are allowed:
+
+1. Certain window/Web Workers-specific APIs, such as `window.innerHeight` and `self.postMessage`
+2. Window-specific events, such as `window.addEventListener('resize')`
+
+## Examples
+
+### Invalid
+
+```js
+window.foo;
+```
+
+
ℹglobalThis is the standard way to access the global object across environments, which improves code portability.
ℹThis rule belongs to the nursery group, which means it is not yet stable and may change in the future. Visit https://biomejs.dev/linter/#nursery for more information.
ℹglobalThis is the standard way to access the global object across environments, which improves code portability.
ℹThis rule belongs to the nursery group, which means it is not yet stable and may change in the future. Visit https://biomejs.dev/linter/#nursery for more information.
+
+### Valid
+
+```js
+globalThis.foo;
+```
+
+```js
+globalThis.addEventListener('click', () => {});
+```
+
+```js
+// window/Web Workers-specific APIs are allowed
+window.innerWidth;
+self.postMessage({ type: 'ready' });
+```
+
+```js
+// window-specific events are allowed
+window.addEventListener('resize', () => {});
+```
+
+## Related links
+
+- [Disable a rule](/linter/#disable-a-rule)
+- [Configure the code fix](/linter#configure-the-code-fix)
+- [Rule options](/linter/#rule-options)
+- [Source Code](https://github.com/biomejs/biome/blob/main/crates/biome_js_analyze/src/lint/nursery/use_global_this.rs)
+- [Test Cases](https://github.com/biomejs/biome/blob/main/crates/biome_js_analyze/tests/specs/nursery/useGlobalThis)
+
+
+
+
diff --git a/src/content/docs/linter/rules/use-input-name.mdx b/src/content/docs/linter/rules/use-input-name.mdx
index 344b4f445..78d6e185f 100644
--- a/src/content/docs/linter/rules/use-input-name.mdx
+++ b/src/content/docs/linter/rules/use-input-name.mdx
@@ -9,13 +9,11 @@ import { Tabs, TabItem } from '@astrojs/starlight/components';
-:::note
-This rule has been implemented but not released yet. It will be available in the next release.
-:::
:::caution
This rule is part of the [nursery](/linter/#nursery) group. This means that it is experimental and the behavior can change at any time.
:::
## Summary
+- Rule available since: `v2.3.14`
- Diagnostic Category: [`lint/nursery/useInputName`](/reference/diagnostics#diagnostic-category)
- This rule doesn't have a fix.
- The default severity of this rule is [**information**](/reference/diagnostics#information).
diff --git a/src/content/docs/linter/rules/use-naming-convention.mdx b/src/content/docs/linter/rules/use-naming-convention.mdx
index 04486e982..ec87288bc 100644
--- a/src/content/docs/linter/rules/use-naming-convention.mdx
+++ b/src/content/docs/linter/rules/use-naming-convention.mdx
@@ -478,29 +478,37 @@ You can select a declaration based on several criteria:
- `importAlias`: default imports and aliases of named imports
- `exportAlias`: aliases of re-exported names
- `variable`: const, let, using, and var declarations
- - `const`
- - `let`
- - `var`
- - `using`
+ - `const`
+ - `let`
+ - `var`
+ - `using`
+
+
- `functionParameter`
- `catchParameter`
- `indexParameter`: parameters of index signatures
- `typeParameter`: generic type parameter
- `classMember`: class properties, parameter properties, methods, getters, and setters
- - `classProperty`: class properties, including parameter properties
- - `classMethod`
- - `classGetter`
- - `classSetter`
- - `objectLiteralMember`: literal object properties, methods, getters, and setters
- - `objectLiteralProperty`
- - `objectLiteralMethod`
- - `objectLiteralGetter`
- - `objectLiteralSetter`
+ - `classProperty`: class properties, including parameter properties
+ - `classMethod`
+ - `classGetter`
+ - `classSetter`
+
+
+ - `objectLiteralMember`: literal object properties, methods, getters, and setters (you might want to duplicate the convention for `typeMember`)
+ - `objectLiteralProperty`
+ - `objectLiteralMethod`
+ - `objectLiteralGetter`
+ - `objectLiteralSetter`
+
+
- `typeMember`: properties, methods, getters, and setters declared in type aliases and interfaces
- - `typeProperty`
- - `typeMethod`
- - `typeGetter`
- - `typeSetter`
+ - `typeProperty`
+ - `typeMethod`
+ - `typeGetter`
+ - `typeSetter`
+
+
- `modifiers`: an array of modifiers among:
diff --git a/src/pages/metadata/rules.json.js b/src/pages/metadata/rules.json.js
index 9fc712785..5acfa5836 100644
--- a/src/pages/metadata/rules.json.js
+++ b/src/pages/metadata/rules.json.js
@@ -250,7 +250,7 @@ export function GET() {
"nursery": {
"noDeprecatedMediaType": {
"deprecated": false,
- "version": "next",
+ "version": "2.3.14",
"name": "noDeprecatedMediaType",
"link": "https://biomejs.dev/linter/rules/no-deprecated-media-type",
"recommended": false,
@@ -293,7 +293,7 @@ export function GET() {
},
"noHexColors": {
"deprecated": false,
- "version": "next",
+ "version": "2.3.14",
"name": "noHexColors",
"link": "https://biomejs.dev/linter/rules/no-hex-colors",
"recommended": false,
@@ -713,7 +713,7 @@ export function GET() {
},
"useInputName": {
"deprecated": false,
- "version": "next",
+ "version": "2.3.14",
"name": "useInputName",
"link": "https://biomejs.dev/linter/rules/use-input-name",
"recommended": false,
@@ -1994,7 +1994,7 @@ export function GET() {
}
}
],
- "docs": " Use arrow functions over function expressions.\n\n An arrow function expression is a compact alternative to a regular function expression,\n with an important distinction:\n `this` is not bound to the arrow function. It inherits `this` from its parent scope.\n\n This rule proposes turning all function expressions that are not generators (`function*`) and don't use `this` into arrow functions.\n\n ## Examples\n\n ### Invalid\n\n ```js,expect_diagnostic\n const z = function() {\n return 0;\n }\n ```\n\n ```js,expect_diagnostic\n const delegatedFetch = async function(url) {\n return await fetch(url);\n }\n ```\n\n ### Valid\n\n ```js\n const f = function() {\n return this.prop;\n }\n ```\n\n Named function expressions are ignored:\n\n ```js\n const z = function z() {\n return 0;\n }\n ```\n\n Functions that reference the [arguments\n object](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/arguments)\n are ignored because the arguments object is not available to arrow\n functions.\n\n ```js\n const q = function () {\n return arguments[0];\n }\n ```\n\n Function expressions that declare the type of `this` are also ignored:\n\n ```ts\n const z = function(this: A): number {\n return 0;\n }\n ```\n"
+ "docs": " Use arrow functions over function expressions.\n\n An arrow function expression is a compact alternative to a regular function expression,\n with an important distinction:\n `this` is not bound to the arrow function. It inherits `this` from its parent scope.\n\n This rule proposes turning all function expressions that are not generators (`function*`) and don't use `this` into arrow functions.\n\n This rule does not modify top-level function declarations ([discuss here](https://github.com/biomejs/biome/discussions/7108)).\n\n ## Examples\n\n ### Invalid\n\n ```js,expect_diagnostic\n const z = function() {\n return 0;\n }\n ```\n\n ```js,expect_diagnostic\n const delegatedFetch = async function(url) {\n return await fetch(url);\n }\n ```\n\n ### Valid\n\n ```js\n const f = function() {\n return this.prop;\n }\n ```\n\n Named function expressions are ignored:\n\n ```js\n const z = function z() {\n return 0;\n }\n ```\n\n Functions that reference the [arguments\n object](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/arguments)\n are ignored because the arguments object is not available to arrow\n functions.\n\n ```js\n const q = function () {\n return arguments[0];\n }\n ```\n\n Function expressions that declare the type of `this` are also ignored:\n\n ```ts\n const z = function(this: A): number {\n return 0;\n }\n ```\n"
},
"useDateNow": {
"deprecated": false,
@@ -3171,6 +3171,23 @@ export function GET() {
],
"docs": " Disallow creating multiline strings by escaping newlines.\n\n Escaping newlines to create multiline strings is discouraged because it\n can lead to subtle errors caused by unexpected whitespace after the\n backslash.\n\n ## Examples\n\n ### Invalid\n\n ```js,expect_diagnostic\n const foo =\n \"Line 1\\n\\\n Line 2\";\n ```\n\n ### Valid\n\n ```js\n const foo = \"Line 1\\nLine 2\";\n ```\n\n ```js\n const bar = `Line 1\n Line 2`;\n ```\n"
},
+ "noNestedPromises": {
+ "deprecated": false,
+ "version": "2.3.15",
+ "name": "noNestedPromises",
+ "link": "https://biomejs.dev/linter/rules/no-nested-promises",
+ "recommended": true,
+ "fixKind": "none",
+ "sources": [
+ {
+ "kind": "sameLogic",
+ "source": {
+ "eslintPromise": "no-nesting"
+ }
+ }
+ ],
+ "docs": " Disallow nested `.then()` or `.catch()` promise calls.\n\n Nesting `.then()` or `.catch()` calls defeats the purpose of promises,\n which is to create a flat chain of asynchronous operations. Nested promise\n callbacks can make code harder to read and maintain.\n\n However, nesting is allowed when the nested callback references variables\n from the outer scope, as flattening would break the code in such cases.\n\n ## Examples\n\n ### Invalid\n\n ```js,expect_diagnostic\n doThing().then(function() { return a.then() })\n ```\n\n ```js,expect_diagnostic\n doThing().then(() => b.catch())\n ```\n\n ```js,expect_diagnostic\n doThing()\n .then(a => getB(a)\n .then(b => getC(b))\n )\n ```\n\n ### Valid\n\n ```js\n // Simple returns\n doThing().then(function() { return 4 })\n doThing().then(() => 4)\n ```\n\n ```js\n // Chained promises (no nesting)\n doThing()\n .then(a => getB(a))\n .then(b => getC(b))\n ```\n\n ```js\n // Nested but references outer scope variable 'a'\n doThing()\n .then(a => getB(a)\n .then(b => getC(a, b))\n )\n ```\n\n ```js\n // Promise.resolve/all are fine\n doThing().then(function() { return Promise.all([a,b,c]) })\n doThing().then(() => Promise.resolve(4))\n ```\n\n"
+ },
"noNextAsyncClientComponent": {
"deprecated": false,
"version": "2.2.0",
@@ -3245,6 +3262,15 @@ export function GET() {
],
"docs": " Replaces usages of `forwardRef` with passing `ref` as a prop.\n\n In React 19, `forwardRef` is no longer necessary. Pass `ref` as a prop instead.\n This rule detects the usage of the `forwardRef` API, and it suggests using the prop `ref`\n instead.\n See [the official blog post](https://react.dev/blog/2024/12/05/react-19#ref-as-a-prop) for details.\n\n This rule should be disabled if you are working with React 18 or earlier.\n\n ## Examples\n\n ### Invalid\n\n ```jsx,expect_diagnostic\n import { forwardRef } from \"react\";\n\n const MyInput = forwardRef(function MyInput(props, ref) {\n return ;\n });\n ```\n\n ```jsx,expect_diagnostic\n import { forwardRef } from \"react\";\n\n const MyInput = forwardRef((props, ref) => {\n return ;\n });\n ```\n\n ### Valid\n\n ```jsx\n function MyInput({ ref, ...props }) {\n return ;\n }\n ```\n\n ```jsx\n const MyInput = ({ ref, ...props }) => {\n return ;\n }\n ```\n\n"
},
+ "noRedundantDefaultExport": {
+ "deprecated": false,
+ "version": "2.3.14",
+ "name": "noRedundantDefaultExport",
+ "link": "https://biomejs.dev/linter/rules/no-redundant-default-export",
+ "recommended": false,
+ "fixKind": "none",
+ "docs": " Checks if a default export exports the same symbol as a named export.\n\n This rule warns when a `default` export references the same identifier as a named export.\n Re-exports are out of scope.\n\n ## Examples\n\n ### Invalid\n\n ```js,expect_diagnostic\n export const foo = 42;\n export default foo;\n ```\n\n ### Valid\n\n ```js\n export const foo = 42;\n export default 42;\n ```\n\n"
+ },
"noReturnAssign": {
"deprecated": false,
"version": "2.3.11",
@@ -3431,6 +3457,23 @@ export function GET() {
"fixKind": "unsafe",
"docs": " Disallow unused catch bindings.\n\n This rule disallows unnecessary catch bindings in accordance with ECMAScript 2019.\n See also: the ECMAScript 2019 “optional catch binding” feature in the language specification.\n\n ## Examples\n\n ### Invalid\n\n ```js,expect_diagnostic\n try {\n // Do something\n } catch (unused) {}\n ```\n\n ```js,expect_diagnostic\n try {\n // Do something\n } catch ({ unused }) {}\n ```\n\n ```js,expect_diagnostic\n try {\n // Do something\n } catch ({ unused1, unused2 }) {}\n ```\n\n ### Valid\n\n ```js\n try {\n // Do something\n } catch (used) {\n console.error(used);\n }\n ```\n\n ```js\n try {\n // Do something\n } catch ({ used }) {\n console.error(used);\n }\n ```\n\n ```js\n try {\n // Do something\n } catch ({ used, unused }) {\n console.error(used);\n }\n ```\n\n ```js\n try {\n // Do something\n } catch {}\n ```\n\n"
},
+ "noUselessReturn": {
+ "deprecated": false,
+ "version": "2.3.15",
+ "name": "noUselessReturn",
+ "link": "https://biomejs.dev/linter/rules/no-useless-return",
+ "recommended": false,
+ "fixKind": "safe",
+ "sources": [
+ {
+ "kind": "inspired",
+ "source": {
+ "eslint": "no-useless-return"
+ }
+ }
+ ],
+ "docs": " Disallow redundant return statements.\n\n A `return;` statement with nothing after it is redundant when it is the\n last reachable statement in a function body. Removing it does not change\n the function's behavior, as execution naturally falls through to the end.\n\n ## Examples\n\n ### Invalid\n\n ```js,expect_diagnostic\n function foo() {\n return;\n }\n ```\n\n ```js,expect_diagnostic\n function foo() {\n doSomething();\n return;\n }\n ```\n\n ```js,expect_diagnostic\n function foo() {\n if (condition) {\n bar();\n return;\n }\n }\n ```\n\n ### Valid\n\n ```js\n function foo() {\n return 5;\n }\n ```\n\n ```js\n function foo() {\n if (condition) {\n return;\n }\n bar();\n }\n ```\n\n ```js\n function foo() {\n for (const x of xs) {\n return;\n }\n }\n ```\n\n"
+ },
"noUselessUndefined": {
"deprecated": false,
"version": "2.0.0",
@@ -3450,7 +3493,7 @@ export function GET() {
},
"noVueArrowFuncInWatch": {
"deprecated": false,
- "version": "next",
+ "version": "2.3.14",
"name": "noVueArrowFuncInWatch",
"link": "https://biomejs.dev/linter/rules/no-vue-arrow-func-in-watch",
"recommended": true,
@@ -3684,6 +3727,23 @@ export function GET() {
],
"docs": " Enforce the use of Array.prototype.find() over Array.prototype.filter() followed by [0] when looking for a single result.\n\n When searching for the first item in an array matching a condition, it may be tempting to use code like `arr.filter(x => x > 0)[0]`.\n However, it is simpler to use `Array.prototype.find()` instead, `arr.find(x => x > 0)`, which also returns the first entry matching a condition.\n Because the `.find()` only needs to execute the callback until it finds a match, it's also more efficient.\n\n ## Examples\n\n ### Invalid\n\n ```ts,expect_diagnostic,file=invalid.ts\n [1, 2, 3].filter(x => x > 1)[0];\n ```\n\n ```ts,expect_diagnostic,file=invalid2.ts\n [1, 2, 3].filter(x => x > 1).at(0);\n ```\n\n ### Valid\n\n ```ts,file=valid.ts\n [1, 2, 3].find(x => x > 1);\n ```\n\n"
},
+ "useGlobalThis": {
+ "deprecated": false,
+ "version": "2.3.14",
+ "name": "useGlobalThis",
+ "link": "https://biomejs.dev/linter/rules/use-global-this",
+ "recommended": false,
+ "fixKind": "none",
+ "sources": [
+ {
+ "kind": "sameLogic",
+ "source": {
+ "eslintUnicorn": "prefer-global-this"
+ }
+ }
+ ],
+ "docs": " Enforce the use of `globalThis` over `window`, `self`, and `global`.\n\n `globalThis` is a standard way to access the global object across platforms such as browsers, Web Workers, Node.js and so on, and using it can make your code portable.\n\n However, there are several exceptions that are allowed:\n\n 1. Certain window/Web Workers-specific APIs, such as `window.innerHeight` and `self.postMessage`\n 2. Window-specific events, such as `window.addEventListener('resize')`\n\n ## Examples\n\n ### Invalid\n\n ```js,expect_diagnostic\n window.foo;\n ```\n\n ```js,expect_diagnostic\n window.addEventListener('click', () => {});\n ```\n\n ### Valid\n\n ```js\n globalThis.foo;\n ```\n\n ```js\n globalThis.addEventListener('click', () => {});\n ```\n\n ```js\n // window/Web Workers-specific APIs are allowed\n window.innerWidth;\n self.postMessage({ type: 'ready' });\n ```\n\n ```js\n // window-specific events are allowed\n window.addEventListener('resize', () => {});\n ```\n\n"
+ },
"useMaxParams": {
"deprecated": false,
"version": "2.2.0",
@@ -3994,6 +4054,12 @@ export function GET() {
"eslintTypeScript": "no-require-imports"
}
},
+ {
+ "kind": "sameLogic",
+ "source": {
+ "eslintTypeScript": "no-var-requires"
+ }
+ },
{
"kind": "sameLogic",
"source": {
@@ -4834,7 +4900,7 @@ export function GET() {
}
}
],
- "docs": " Disallow assignments in expressions.\n\n In expressions, it is common to mistype a comparison operator (such as `==`) as an assignment operator (such as `=`).\n Moreover, the use of assignments in expressions is confusing.\n Indeed, expressions are often considered as side-effect free.\n\n ## Examples\n\n ### Invalid\n\n ```ts,expect_diagnostic\n let a, b;\n a = (b = 1) + 1;\n ```\n\n ```ts,expect_diagnostic\n let a;\n if (a = 1) {\n }\n ```\n\n ```ts,expect_diagnostic\n function f(a) {\n return a = 1;\n }\n ```\n\n ### Valid\n\n ```ts\n let a;\n a = 1;\n ```\n"
+ "docs": " Disallow assignments in expressions.\n\n In expressions, it is common to mistype a comparison operator (such as `==`) as an assignment operator (such as `=`).\n Moreover, the use of assignments in expressions is confusing.\n Indeed, expressions are often considered as side-effect free.\n\n ## Examples\n\n ### Invalid\n\n ```ts,expect_diagnostic\n let a, b;\n a = (b = 1) + 1;\n ```\n\n ```ts,expect_diagnostic\n let a;\n if (a = 1) {\n }\n ```\n\n ```ts,expect_diagnostic\n function f(a) {\n return a = 1;\n }\n ```\n\n ### Valid\n\n ```ts\n let a;\n a = 1;\n ```\n\n ```ts\n let a = 0;\n const f = b => a += b;\n ```\n"
},
"noAsyncPromiseExecutor": {
"deprecated": false,
@@ -5793,7 +5859,7 @@ export function GET() {
}
}
],
- "docs": " Ensure `async` functions utilize `await`.\n\n This rule reports `async` functions that lack an `await` expression. As `async`\n functions return a promise, the use of `await` is often necessary to capture the\n resolved value and handle the asynchronous operation appropriately. Without `await`,\n the function operates synchronously and might not leverage the advantages of async\n functions.\n\n ## Examples\n\n ### Invalid\n\n ```js,expect_diagnostic\n async function fetchData() {\n // Missing `await` for the promise returned by `fetch`\n return fetch('/data');\n }\n ```\n\n ### Valid\n\n ```js\n async function fetchData() {\n const response = await fetch('/data');\n const data = await response.json();\n return data;\n }\n\n // This rule does not warn about non-async functions\n function processData() {\n return compute(data);\n }\n\n // Nor does it warn about empty `async` functions\n async function noop() { }\n ```\n"
+ "docs": " Ensure `async` functions utilize `await`.\n\n This rule reports `async` functions that lack an `await` expression. As `async`\n functions return a promise, the use of `await` is often necessary to capture the\n resolved value and handle the asynchronous operation appropriately. Without `await`,\n the function operates synchronously and might not leverage the advantages of async\n functions.\n\n ## Examples\n\n ### Invalid\n\n ```js,expect_diagnostic\n async function fetchData() {\n // Missing `await` for the promise returned by `fetch`\n return fetch('/data');\n }\n ```\n\n ### Valid\n\n ```js\n async function fetchData() {\n const response = await fetch('/data');\n const data = await response.json();\n return data;\n }\n\n // This rule does not warn about non-async functions\n function processData() {\n return compute(data);\n }\n\n // Nor does it warn about empty `async` functions\n async function noop() { }\n\n // Async generators that use `yield*` with an async iterable\n async function* delegateToAsyncIterable() {\n yield* otherAsyncIterable();\n }\n ```\n"
},
"useDefaultSwitchClauseLast": {
"deprecated": false,
@@ -6740,7 +6806,7 @@ export function GET() {
}
}
],
- "docs": " Enforce correct dependency usage within React hooks.\n\n React components have access to various [hooks](https://react.dev/reference/react/hooks) that can perform\n various actions like querying and updating state.\n\n For hooks that trigger whenever a variable changes (such as `useEffect` and `useMemo`),\n React relies on the hook's listed dependencies array to determine when to re-compute Effects and re-render the page.\n\n This can lead to unexpected behavior when dependencies are incorrectly specified:\n ```jsx,ignore\n\n function ticker() {\n const [count, setCount] = useState(0);\n\n /** Increment the count once per second. */\n function onTick() {\n setCount(count + 1);\n }\n\n // React _thinks_ this code doesn't depend on anything else, so\n // it will only use the _initial_ version of `onTick` when rendering the component.\n // As a result, our normally-dynamic counter will always display 1!\n // This is referred to as a \"stale closure\", and is a common pitfall for beginners.\n useEffect(() => {\n const id = setInterval(onTick, 1000);\n return () => clearInterval(id);\n }, []);\n\n return
Counter: {count}
;\n }\n ```\n\n ```jsx,ignore\n function apples() {\n const [count, setCount] = useState(0);\n const [message, setMessage] = useState(\"We have 0 apples!\");\n\n // React _thinks_ this code depends on BOTH `count` and `message`, and will re-run the hook whenever\n // `message` is changed despite it not actually being used inside the closure.\n // In fact, this will create an infinite loop due to our hook updating `message` and triggering itself again!\n useEffect(() => {\n setMessage(`We have ${count} apples!`)\n }, [count, message]);\n\n }\n ```\n\n This rule attempts to prevent such issues by diagnosing potentially incorrect or invalid usages of hook dependencies.\n\n ### Default Behavior\n By default, the following hooks (and their Preact counterparts) will have their arguments checked by this rule:\n\n - `useEffect`\n - `useLayoutEffect`\n - `useInsertionEffect`\n - `useCallback`\n - `useMemo`\n - `useImperativeHandle`\n\n #### Stable results\n When a hook is known to have a stable return value (one whose identity doesn't change across invocations),\n that value doesn't need to and _should not_ be specified as a dependency.\n For example, setters returned by React's `useState` hook will not change throughout the lifetime of a program\n and should therefore be omitted.\n\n By default, the following hooks are considered to have stable return values:\n - `useState` (index 1)\n - `useReducer` (index 1)\n - `useTransition` (index 1)\n - `useRef`\n - `useEffectEvent`\n\n If you want to add custom hooks to the rule's diagnostics or specify your own functions with stable results,\n see the [options](#options) section for more information.\n\n ## Examples\n\n ### Invalid\n\n ```js,expect_diagnostic\n import { useEffect } from \"react\";\n\n function component() {\n let a = 1;\n useEffect(() => {\n console.log(a);\n }, []);\n }\n ```\n\n ```js,expect_diagnostic\n import { useEffect } from \"react\";\n\n function badComponent() {\n let a = 1;\n useEffect(() => {\n console.log(a);\n }, \"not an array\");\n }\n ```\n\n ```js,expect_diagnostic\n import { useEffect } from \"react\";\n\n function component() {\n let unused = 1;\n useEffect(() => {}, [unused]);\n }\n ```\n\n ```js,expect_diagnostic\n import { useEffect, useState } from \"react\";\n\n function component() {\n const [name, setName] = useState();\n useEffect(() => {\n console.log(name);\n setName(\"i never change and don't need to be here\");\n }, [name, setName]);\n }\n ```\n\n ```js,expect_diagnostic\n import { useEffect, useState } from \"react\";\n\n function component() {\n const name = \"foo\"\n // name doesn't change, so specifying it is redundant\n useEffect(() => {\n console.log(name);\n }, [name]);\n }\n ```\n\n ```js,expect_diagnostic\n import { useEffect } from \"react\";\n\n function component() {\n let a = 1;\n const b = a + 1;\n useEffect(() => {\n console.log(b);\n }, []);\n }\n ```\n\n ### Valid\n\n ```js\n import { useEffect } from \"react\";\n\n function component() {\n let a = 1;\n useEffect(() => {\n console.log(a);\n }, [a]);\n }\n ```\n\n ```js\n import { useEffect } from \"react\";\n\n function component() {\n const SECONDS_PER_DAY = 60 * 60 * 24;\n useEffect(() => {\n console.log(SECONDS_PER_DAY);\n });\n }\n ```\n\n ```js\n import { useEffect, useState } from \"react\";\n\n function component() {\n const [name, setName] = useState();\n useEffect(() => {\n console.log(name);\n setName(\"\");\n }, [name]);\n }\n ```\n\n Hooks not imported from React are ignored by default (unless specified inside [rule options](#options))\n ```ts\n import type { EffectCallback, DependencyList } from \"react\";\n // custom useEffect function\n declare function useEffect(cb: EffectCallback, deps?: DependencyList): void;\n\n function component() {\n let name = \"John Doe\";\n useEffect(() => {\n console.log(name);\n }, []);\n }\n ```\n\n ## Ignoring a specific dependency\n\n Sometimes you may wish to ignore a diagnostic about a specific\n dependency without disabling *all* linting for that hook. To do so,\n you may specify the name of a specific dependency between parentheses,\n like this:\n\n ```js\n import { useEffect } from \"react\";\n\n function component() {\n let a = 1;\n // biome-ignore lint/correctness/useExhaustiveDependencies(a): suppress dependency a\n useEffect(() => {\n console.log(a);\n }, []);\n }\n ```\n\n If you wish to ignore multiple dependencies, you can add multiple\n comments and add a reason for each:\n\n ```js\n import { useEffect } from \"react\";\n\n function component() {\n let a = 1;\n let b = 1;\n // biome-ignore lint/correctness/useExhaustiveDependencies(a): suppress dependency a\n // biome-ignore lint/correctness/useExhaustiveDependencies(b): suppress dependency b\n useEffect(() => {\n console.log(a, b);\n }, []);\n }\n ```\n\n :::caution\n Mismatching code & dependencies has a **very high risk** of creating bugs in your components.\n By suppressing the linter, you “lie” to React about the values your Effect depends on,\n so prefer changing the code over suppressing the rule where possible.\n :::\n\n ## Options\n\n ### `hooks`\n Allows specifying custom hooks (from libraries or internal projects) whose dependencies\n should be checked and/or which are known to have stable return values.\n\n For every hook whose dependencies you want validated, you must specify the index of both the closure\n using the dependencies and the dependencies array to validate it against.\n\n ##### Example\n\n ```json,options\n {\n \"options\": {\n \"hooks\": [\n { \"name\": \"useLocation\", \"closureIndex\": 0, \"dependenciesIndex\": 1 },\n { \"name\": \"useQuery\", \"closureIndex\": 2, \"dependenciesIndex\": 0 }\n ]\n }\n }\n ```\n\n This would enable checks on the following code snippets:\n\n ```js,expect_diagnostic,use_options\n function Foo() {\n let stateVar = 1;\n useLocation(() => {console.log(stateVar)}, []);\n }\n ```\n ```js,use_options\n function Foo() {\n let stateVar = 1;\n useQuery([stateVar], \"smthng\", () => {console.log(stateVar)});\n }\n ```\n\n #### Configuring stable results\n\n As previously discussed, the lint rule takes into account so-called [stable results](#stable-results)\n and will ensure any such variables are _not_ specified as dependencies.\n\n You can specify custom functions as returning stable results in one of four ways:\n\n 1. `\"stableResult\": true` -- marks the return value as stable. An example\n of a React hook that would be configured like this is `useRef()`.\n 2. `\"stableResult\": [1]` -- expects the return value to be an array and\n marks the given indices as stable. An example of a React\n hook that would be configured like this is `useState()`.\n 3. `\"stableResult\": 1` -- shorthand for option 2 (`\"stableResult\": [1]`).\n Useful for hooks that only have a single stable return.\n 4. `\"stableResult\": [\"setValue\"]` -- expects the return value to be an\n object and marks the properties with the given keys as stable.\n\n ##### Example\n\n ```json,options\n {\n \"options\": {\n \"hooks\": [\n { \"name\": \"useDispatch\", \"stableResult\": true }\n ]\n }\n }\n ```\n\n With this configuration, the following is valid:\n\n ```js,use_options\n const dispatch = useDispatch();\n // No need to list `dispatch` as dependency since it doesn't change\n const doAction = useCallback(() => dispatch(someAction()), []);\n ```\n\n ### `reportUnnecessaryDependencies`\n\n If set to `false`, the rule will not trigger diagnostics for unused dependencies passed to hooks that do not use them.\n\n :::caution\n Over-specifying dependencies can reduce application performance or even cause infinite loops, so caution is advised.\n :::\n\n Default: `true`\n\n ##### Example\n\n ```json,options\n {\n \"options\": {\n \"reportUnnecessaryDependencies\": false\n }\n }\n ```\n\n ```jsx,use_options\n import { useEffect } from \"react\";\n\n function Foo() {\n let stateVar = 1;\n // not used but still OK\n useEffect(() => {}, [stateVar]);\n }\n ```\n\n ### `reportMissingDependenciesArray`\n\n If enabled, the rule will also trigger diagnostics for hooks that lack dependency arrays altogether,\n requiring any hooks lacking dependencies to explicitly specify an empty array.\n\n Default: `false`\n\n ##### Example\n\n ```json,options\n {\n \"options\": {\n \"reportMissingDependenciesArray\": true\n }\n }\n ```\n\n ```jsx,expect_diagnostic,use_options\n function noArrayYesProblem() {\n let stateVar = 1;\n React.useEffect(() => {});\n }\n ```\n\n"
+ "docs": " Enforce correct dependency usage within React hooks.\n\n React components have access to various [hooks](https://react.dev/reference/react/hooks) that can perform\n various actions like querying and updating state.\n\n For hooks that trigger whenever a variable changes (such as `useEffect` and `useMemo`),\n React relies on the hook's listed dependencies array to determine when to re-compute Effects and re-render the page.\n\n This can lead to unexpected behavior when dependencies are incorrectly specified:\n ```jsx,ignore\n\n function ticker() {\n const [count, setCount] = useState(0);\n\n /** Increment the count once per second. */\n function onTick() {\n setCount(count + 1);\n }\n\n // React _thinks_ this code doesn't depend on anything else, so\n // it will only use the _initial_ version of `onTick` when rendering the component.\n // As a result, our normally-dynamic counter will always display 1!\n // This is referred to as a \"stale closure\", and is a common pitfall for beginners.\n useEffect(() => {\n const id = setInterval(onTick, 1000);\n return () => clearInterval(id);\n }, []);\n\n return
Counter: {count}
;\n }\n ```\n\n ```jsx,ignore\n function apples() {\n const [count, setCount] = useState(0);\n const [message, setMessage] = useState(\"We have 0 apples!\");\n\n // React _thinks_ this code depends on BOTH `count` and `message`, and will re-run the hook whenever\n // `message` is changed despite it not actually being used inside the closure.\n // In fact, this will create an infinite loop due to our hook updating `message` and triggering itself again!\n useEffect(() => {\n setMessage(`We have ${count} apples!`)\n }, [count, message]);\n\n }\n ```\n\n This rule attempts to prevent such issues by diagnosing potentially incorrect or invalid usages of hook dependencies.\n\n ### Default Behavior\n By default, the following hooks (and their Preact counterparts) will have their arguments checked by this rule:\n\n - `useEffect`\n - `useLayoutEffect`\n - `useInsertionEffect`\n - `useCallback`\n - `useMemo`\n - `useImperativeHandle`\n\n #### Stable results\n When a hook is known to have a stable return value (one whose identity doesn't change across invocations),\n that value doesn't need to and _should not_ be specified as a dependency.\n For example, setters returned by React's `useState` hook will not change throughout the lifetime of a program\n and should therefore be omitted.\n\n By default, the following hooks are considered to have stable return values:\n - `useState` (index 1)\n - `useReducer` (index 1)\n - `useTransition` (index 1)\n - `useRef`\n - `useEffectEvent`\n\n If you want to add custom hooks to the rule's diagnostics or specify your own functions with stable results,\n see the [options](#options) section for more information.\n\n ## Examples\n\n ### Invalid\n\n ```js,expect_diagnostic\n import { useEffect } from \"react\";\n\n function component() {\n let a = 1;\n useEffect(() => {\n console.log(a);\n }, []);\n }\n ```\n\n ```js,expect_diagnostic\n import { useEffect } from \"react\";\n\n function badComponent() {\n let a = 1;\n useEffect(() => {\n console.log(a);\n }, \"not an array\");\n }\n ```\n\n ```js,expect_diagnostic\n import { useEffect } from \"react\";\n\n function component() {\n let unused = 1;\n useEffect(() => {}, [unused]);\n }\n ```\n\n ```js,expect_diagnostic\n import { useEffect, useState } from \"react\";\n\n function component() {\n const [name, setName] = useState();\n useEffect(() => {\n console.log(name);\n setName(\"i never change and don't need to be here\");\n }, [name, setName]);\n }\n ```\n\n ```js,expect_diagnostic\n import { useEffect, useState } from \"react\";\n\n function component() {\n const name = \"foo\"\n // name doesn't change, so specifying it is redundant\n useEffect(() => {\n console.log(name);\n }, [name]);\n }\n ```\n\n ```js,expect_diagnostic\n import { useEffect } from \"react\";\n\n function component() {\n let a = 1;\n const b = a + 1;\n useEffect(() => {\n console.log(b);\n }, []);\n }\n ```\n\n ```jsx,expect_diagnostic\n import { useCallback } from \"react\";\n\n function component() {\n const Component = () => null;\n const render = useCallback(() => , []);\n }\n ```\n\n ### Valid\n\n ```js\n import { useEffect } from \"react\";\n\n function component() {\n let a = 1;\n useEffect(() => {\n console.log(a);\n }, [a]);\n }\n ```\n\n ```js\n import { useEffect } from \"react\";\n\n function component() {\n const SECONDS_PER_DAY = 60 * 60 * 24;\n useEffect(() => {\n console.log(SECONDS_PER_DAY);\n });\n }\n ```\n\n ```js\n import { useEffect, useState } from \"react\";\n\n function component() {\n const [name, setName] = useState();\n useEffect(() => {\n console.log(name);\n setName(\"\");\n }, [name]);\n }\n ```\n\n Hooks not imported from React are ignored by default (unless specified inside [rule options](#options))\n ```ts\n import type { EffectCallback, DependencyList } from \"react\";\n // custom useEffect function\n declare function useEffect(cb: EffectCallback, deps?: DependencyList): void;\n\n function component() {\n let name = \"John Doe\";\n useEffect(() => {\n console.log(name);\n }, []);\n }\n ```\n\n ## Ignoring a specific dependency\n\n Sometimes you may wish to ignore a diagnostic about a specific\n dependency without disabling *all* linting for that hook. To do so,\n you may specify the name of a specific dependency between parentheses,\n like this:\n\n ```js\n import { useEffect } from \"react\";\n\n function component() {\n let a = 1;\n // biome-ignore lint/correctness/useExhaustiveDependencies(a): suppress dependency a\n useEffect(() => {\n console.log(a);\n }, []);\n }\n ```\n\n If you wish to ignore multiple dependencies, you can add multiple\n comments and add a reason for each:\n\n ```js\n import { useEffect } from \"react\";\n\n function component() {\n let a = 1;\n let b = 1;\n // biome-ignore lint/correctness/useExhaustiveDependencies(a): suppress dependency a\n // biome-ignore lint/correctness/useExhaustiveDependencies(b): suppress dependency b\n useEffect(() => {\n console.log(a, b);\n }, []);\n }\n ```\n\n :::caution\n Mismatching code & dependencies has a **very high risk** of creating bugs in your components.\n By suppressing the linter, you “lie” to React about the values your Effect depends on,\n so prefer changing the code over suppressing the rule where possible.\n :::\n\n ## Options\n\n ### `hooks`\n Allows specifying custom hooks (from libraries or internal projects) whose dependencies\n should be checked and/or which are known to have stable return values.\n\n For every hook whose dependencies you want validated, you must specify the index of both the closure\n using the dependencies and the dependencies array to validate it against.\n\n ##### Example\n\n ```json,options\n {\n \"options\": {\n \"hooks\": [\n { \"name\": \"useLocation\", \"closureIndex\": 0, \"dependenciesIndex\": 1 },\n { \"name\": \"useQuery\", \"closureIndex\": 2, \"dependenciesIndex\": 0 }\n ]\n }\n }\n ```\n\n This would enable checks on the following code snippets:\n\n ```js,expect_diagnostic,use_options\n function Foo() {\n let stateVar = 1;\n useLocation(() => {console.log(stateVar)}, []);\n }\n ```\n ```js,use_options\n function Foo() {\n let stateVar = 1;\n useQuery([stateVar], \"smthng\", () => {console.log(stateVar)});\n }\n ```\n\n #### Configuring stable results\n\n As previously discussed, the lint rule takes into account so-called [stable results](#stable-results)\n and will ensure any such variables are _not_ specified as dependencies.\n\n You can specify custom functions as returning stable results in one of four ways:\n\n 1. `\"stableResult\": true` -- marks the return value as stable. An example\n of a React hook that would be configured like this is `useRef()`.\n 2. `\"stableResult\": [1]` -- expects the return value to be an array and\n marks the given indices as stable. An example of a React\n hook that would be configured like this is `useState()`.\n 3. `\"stableResult\": 1` -- shorthand for option 2 (`\"stableResult\": [1]`).\n Useful for hooks that only have a single stable return.\n 4. `\"stableResult\": [\"setValue\"]` -- expects the return value to be an\n object and marks the properties with the given keys as stable.\n\n ##### Example\n\n ```json,options\n {\n \"options\": {\n \"hooks\": [\n { \"name\": \"useDispatch\", \"stableResult\": true }\n ]\n }\n }\n ```\n\n With this configuration, the following is valid:\n\n ```js,use_options\n const dispatch = useDispatch();\n // No need to list `dispatch` as dependency since it doesn't change\n const doAction = useCallback(() => dispatch(someAction()), []);\n ```\n\n ### `reportUnnecessaryDependencies`\n\n If set to `false`, the rule will not trigger diagnostics for unused dependencies passed to hooks that do not use them.\n\n :::caution\n Over-specifying dependencies can reduce application performance or even cause infinite loops, so caution is advised.\n :::\n\n Default: `true`\n\n ##### Example\n\n ```json,options\n {\n \"options\": {\n \"reportUnnecessaryDependencies\": false\n }\n }\n ```\n\n ```jsx,use_options\n import { useEffect } from \"react\";\n\n function Foo() {\n let stateVar = 1;\n // not used but still OK\n useEffect(() => {}, [stateVar]);\n }\n ```\n\n ### `reportMissingDependenciesArray`\n\n If enabled, the rule will also trigger diagnostics for hooks that lack dependency arrays altogether,\n requiring any hooks lacking dependencies to explicitly specify an empty array.\n\n Default: `false`\n\n ##### Example\n\n ```json,options\n {\n \"options\": {\n \"reportMissingDependenciesArray\": true\n }\n }\n ```\n\n ```jsx,expect_diagnostic,use_options\n function noArrayYesProblem() {\n let stateVar = 1;\n React.useEffect(() => {});\n }\n ```\n\n"
},
"useHookAtTopLevel": {
"deprecated": false,
@@ -7432,6 +7498,23 @@ export function GET() {
],
"docs": " Disallow enums from having both number and string members.\n\n TypeScript enums are allowed to assign numeric or string values to their members.\n Most enums contain either all numbers or all strings, but in theory you can mix-and-match within the same enum.\n Mixing enum member types is generally considered confusing and a bad practice.\n\n ## Examples\n\n ### Invalid\n\n ```ts,expect_diagnostic\n enum Status {\n Unknown,\n Closed = 1,\n Open = 'open',\n }\n ```\n\n ### Valid\n\n ```ts\n enum Status {\n Unknown = 0,\n Closed = 1,\n Open = 2,\n }\n ```\n\n ```ts\n enum Status {\n Unknown,\n Closed,\n Open,\n }\n ```\n\n ```ts\n enum Status {\n Unknown = 'unknown',\n Closed = 'closed',\n Open = 'open',\n }\n ```\n\n"
},
+ "useConsistentMethodSignatures": {
+ "deprecated": false,
+ "version": "2.3.14",
+ "name": "useConsistentMethodSignatures",
+ "link": "https://biomejs.dev/linter/rules/use-consistent-method-signatures",
+ "recommended": false,
+ "fixKind": "none",
+ "sources": [
+ {
+ "kind": "sameLogic",
+ "source": {
+ "eslintTypeScript": "method-signature-style"
+ }
+ }
+ ],
+ "docs": " Enforce consistent use of either method signatures or function properties within interfaces and type aliases.\n\n TypeScript provides 2 different ways to declare methods within interfaces and object types:\n ```ts,ignore\n interface Example {\n // method shorthand syntax\n methodFunc(arg: string): void;\n\n // regular property with function type\n prop: (arg: string) => void;\n }\n\n // These forms correspond to the analogous JS object literal patterns:\n const obj = {\n methodFunc(arg) {},\n prop: (arg) => {},\n } satisfies Example;\n ```\n\n While mostly a matter of stylistic consistency, the two gain subtle differences in behavior when the\n [`strictFunctionTypes`](https://www.typescriptlang.org/tsconfig/#strictFunctionTypes) compiler option is enabled. \\\n More specifically, its stricter contravariant checks will **only** apply to functions written in _property_ syntax —\n ones written as methods will remain with the weaker bivariant type checks.\n\n \n What's the difference?\n\n To illustrate the differences between method bivariance and contravariance, consider the following snippet of code:\n ```ts,ignore\n interface Emitter {\n methodFunc(arg: Event): void;\n propFunc: (arg: Event) => void;\n }\n\n interface SpecialEvent extends Event {\n isBirthday: boolean;\n }\n\n interface SpecialEmitter extends Emitter {\n methodFunc(arg: SpecialEvent): void; // OK\n propFunc: (arg: SpecialEvent) => void; // Error under `strictFunctionTypes`\n }\n ```\n In the above example, `SpecialEmitter.methodFunc` is compatible with `Emitter.methodFunc` under _bivariant_[^1] checks,\n as `SpecialEvent` is assignable to `Event` (i.e. all `SpecialEvent`s are guaranteed to be valid `Event`s). \\\n On the other hand, the strict _contravariant_ checks for function properties produce errors on `propFunc` as the reverse is not guaranteed —\n `Event` is not assignable to `SpecialEvent` (i.e. not all `Event`s are guaranteed to be valid `SpecialEvent`s).\n\n The full rationale for this behavior can be found in the [TypeScript handbook](https://www.typescriptlang.org/docs/handbook/type-compatibility.html#function-parameter-bivariance).\n\n [^1]: From a purely type-theoretical perspective, bivariance technically refers to a type being _both_ covariant _and_ contravariant at once\n (`A` ⊆ `B` implies `T` ≣ `T`). \\\n In practice, this is only true for pathological types like `type T = number`,\n and so is often used to refer to a type being either covariant _or_ contravariant (which simply requires `T` and `T` to have some non-zero amount of overlap).\n\n \n\n To avoid inconsistent type assignability issues and enforce stylistic consistency, this rule attempts to\n ensure either method- or property-style declarations are used consistently across a given codebase.\n\n :::info\n Without `strictFunctionTypes` enabled, method signatures and function properties become **functionally identical**.\n In this case, which option to use simply becomes a matter of personal preference.\n :::\n\n ## Examples\n\n ### Invalid\n\n ```ts,expect_diagnostic\n interface Example {\n methodFunc(arg: string): number;\n }\n ```\n\n ```ts,expect_diagnostic\n type Generic = {\n methodFunc(arg: T): U;\n }\n ```\n\n ```ts,expect_diagnostic\n type Union =\n | {\n foo(bar: number): number;\n }\n | 4;\n ```\n\n ```ts,expect_diagnostic\n type Intersection =\n {\n qux(quux: number): \"quuux\";\n } & { foo: string };\n ```\n\n ### Valid\n\n ```ts\n interface Prop {\n propFunc: (arg: string) => number;\n }\n ```\n\n ```ts\n type Thing = {\n genericProp: (arg: U) => T;\n }\n ```\n\n ```ts\n type Callback = () => void;\n ```\n\n Classes (as well as interfaces lacking function declarations) are always ignored:\n ```ts\n interface Example {\n notAFunc: number;\n }\n ```\n\n ```ts\n class Foo {\n methodFunc(arg: string): number;\n }\n ```\n\n ## Options\n\n ### `style`\n The desired method signature style to enforce. \\\n Possible values are either `\"method\"` or `\"property\"`.\n\n Default: `\"property\"`[^2]\n\n #### Examples for `\"style\": \"method\"`\n\n ```json,options\n {\n \"options\": {\n \"style\": \"method\"\n }\n }\n ```\n\n ```ts,use_options,expect_diagnostic\n interface Blah {\n propFunc: (arg: string) => void;\n }\n ```\n\n ```ts,use_options,expect_diagnostic\n type Generic = {\n propFunc: (arg: T) => U;\n }\n ```\n\n ```ts,use_options\n type OK = {\n flubber(arg: number): number;\n }\n ```\n\n [^2]: Chosen to allow stricter type checks under the aforementioned `strictFunctionTypes`.\n"
+ },
"useExplicitType": {
"deprecated": false,
"version": "1.9.3",
@@ -7643,7 +7726,7 @@ export function GET() {
}
}
],
- "docs": " Enforce type definitions to consistently use either `interface` or `type`.\n\n _TypeScript_ provides two different ways to define an object type: `interface` and `type`.\n\n This rule enforces consistent usage of either `interface` or `type` for object type definitions.\n Consistent type definition styles, aside from improving code readability, help minimize cognitive load when developers\n switch between different codebases or within a large codebase.\n\n ## Example\n\n ### Invalid\n\n ```ts,expect_diagnostic\n type Point = { x: number; y: number; };\n ```\n\n ### Valid\n\n ```ts\n interface Point {\n x: number;\n y: number;\n }\n ```\n\n ## Options\n\n The following options are available\n\n ### `style`\n\n This option will determine which style to use for type definitions.\n\n Default: `interface`\n\n ```json,options\n {\n \"options\": {\n \"style\": \"type\"\n }\n }\n ```\n\n ```ts,use_options,expect_diagnostic\n interface Point {\n x: number;\n y: number;\n }\n ```\n\n"
+ "docs": " Enforce type definitions to consistently use either `interface` or `type`.\n\n _TypeScript_ provides two different ways to define an object type: `interface` and `type`.\n\n This rule enforces consistent usage of either `interface` or `type` for object type definitions.\n Consistent type definition styles, aside from improving code readability, help minimize cognitive load when developers\n switch between different codebases or within a large codebase.\n\n Empty object type declarations will be left as-is and will not be converted to interfaces,\n as it will conflict with the `noEmptyInterface` rule.\n\n ## Example\n\n ### Invalid\n\n ```ts,expect_diagnostic\n type Point = { x: number; y: number; };\n ```\n\n ### Valid\n\n ```ts\n interface Point {\n x: number;\n y: number;\n }\n ```\n\n ```ts\n type AnyObject = {};\n ```\n\n ## Options\n\n The following options are available\n\n ### `style`\n\n This option will determine which style to use for type definitions.\n\n Default: `interface`\n\n ```json,options\n {\n \"options\": {\n \"style\": \"type\"\n }\n }\n ```\n\n ```ts,use_options,expect_diagnostic\n interface Point {\n x: number;\n y: number;\n }\n ```\n\n"
},
"useEnumInitializers": {
"deprecated": false,
@@ -7728,7 +7811,7 @@ export function GET() {
}
}
],
- "docs": " Enforce naming conventions for everything across a codebase.\n\n Enforcing [naming conventions](https://en.wikipedia.org/wiki/Naming_convention_(programming)) helps to keep the codebase consistent,\n and reduces overhead when thinking about the name [case] of a variable.\n\n The following section describes the default conventions enforced by the rule.\n You can also enforce custom conventions with the [rule options](#options).\n\n ## Naming conventions\n\n All names can be prefixed and suffixed with underscores `_` and dollar signs `$`.\n Unused variables with a name prefixed with `_` are completely ignored.\n This avoids conflicts with the `noUnusedVariables` rule.\n\n ### Variable and parameter names\n\n All variables and function parameters are in [`camelCase`] or [`PascalCase`].\n Catch parameters are in [`camelCase`].\n\n Additionally, global variables declared as `const` or `var` may be in [`CONSTANT_CASE`].\n Global variables are declared at module or script level.\n Variables declared in a TypeScript `namespace` are also considered global.\n\n ```js\n function f(param, _unusedParam) {\n let localValue = 0;\n try {\n /* ... */\n } catch (customError) {\n /* ... */\n }\n }\n\n export const A_CONSTANT = 5;\n\n let aVariable = 0;\n\n export namespace ns {\n export const ANOTHER_CONSTANT = \"\";\n }\n ```\n\n Examples of incorrect names:\n\n ```js,expect_diagnostic\n let a_value = 0;\n ```\n\n ```js,expect_diagnostic\n const fooYPosition = 0;\n ```\n\n ```js,expect_diagnostic\n function f(FIRST_PARAM) {}\n ```\n\n ### Function names\n\n - A `function` name is in [`camelCase`] or [`PascalCase`].\n - A global `function` can also be in `UPPERCASE`.\n This allows supporting the frameworks that require some function to use valid [HTTP method names](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods).\n\n ```jsx\n function trimString(s) { /*...*/ }\n\n function Component() {\n return ;\n }\n\n export function GET() { /*...*/ }\n ```\n\n ### TypeScript `enum` names\n\n A _TypeScript_ `enum` name is in [`PascalCase`].\n\n `enum` members are by default in [`PascalCase`].\n However, you can configure the [case] of `enum` members.\n See [options](#options) for more details.\n\n ```ts\n enum Status {\n Open,\n Close,\n }\n ```\n\n ### Classes\n\n - A class name is in [`PascalCase`].\n\n - Static property and static getter names are in [`camelCase`] or [`CONSTANT_CASE`].\n\n - Class property and method names are in [`camelCase`].\n\n ```js\n class Person {\n static MAX_FRIEND_COUNT = 256;\n\n static get SPECIAL_PERSON_INSTANCE() { /*...*/ }\n\n initializedProperty = 0;\n\n specialMethod() {}\n }\n ```\n\n ### TypeScript `type` aliases and `interface`\n\n - A `type` alias or an interface name are in [`PascalCase`].\n\n - Member names of a type are in [`camelCase`].\n\n - `readonly` property and getter names can also be in [`CONSTANT_CASE`].\n\n ```ts\n type Named = {\n readonly fullName: string;\n\n specialMethod(): void;\n };\n\n interface Named {\n readonly fullName: string;\n\n specialMethod(): void;\n }\n\n interface PersonConstructor {\n readonly MAX_FRIEND_COUNT: number;\n\n get SPECIAL_PERSON_INSTANCE(): Person;\n\n new(): Person;\n }\n ```\n\n Examples of an incorrect type alias:\n\n ```ts,expect_diagnostic\n type person = { fullName: string };\n ```\n\n ### Literal object member names\n\n - Literal object members are in [`camelCase`].\n\n ```js\n const alice = {\n fullName: \"Alice\",\n }\n ```\n\n Example of an incorrect name:\n\n ```js,expect_diagnostic\n const alice = {\n full_name: \"Alice\",\n }\n ```\n\n ### Import and export aliases and namespaces\n\n Import and export namespaces are in [`camelCase`] or [`PascalCase`].\n\n ```js\n import * as myLib from \"my-lib\";\n import * as Framework from \"framework\";\n\n export * as myLib from \"my-lib\";\n export * as Framework from \"framework\";\n ```\n\n `import` and `export` aliases are in [`camelCase`], [`PascalCase`], or [`CONSTANT_CASE`]:\n\n ```js\n import assert, {\n deepStrictEqual as deepEqual,\n AssertionError as AssertError\n } from \"node:assert\";\n ```\n\n Examples of an incorrect name:\n\n ```ts,expect_diagnostic\n import * as MY_LIB from \"my-lib\";\n ```\n\n ### TypeScript type parameter names\n\n A _TypeScript_ type parameter name is in [`PascalCase`].\n\n ```ts\n function id(value: Val): Val { /* ... */}\n ```\n\n ### TypeScript `namespace` names\n\n A _TypeScript_ `namespace` name is in [`camelCase`] or in [`PascalCase`].\n\n ```ts\n namespace mathExtra {\n /*...*/\n }\n\n namespace MathExtra {\n /*...*/\n }\n ```\n\n ## Ignored declarations\n\n Note that some declarations are always ignored.\n You cannot apply a convention to them.\n This is the case for:\n\n - Member names that are not identifiers\n\n ```js\n class C {\n [\"not an identifier\"]() {}\n }\n ```\n\n - Named imports\n\n ```js\n import { an_IMPORT } from \"mod\"\n ```\n\n - Destructured object properties\n\n ```js\n const { destructed_PROP } = obj;\n ```\n\n - Class members marked with `override`:\n\n ```ts\n class C extends B {\n override overridden_METHOD() {}\n }\n ```\n\n - Declarations inside an external TypeScript module\n\n ```ts\n declare module \"myExternalModule\" {\n export interface my_INTERFACE {}\n }\n ```\n\n - Declarations inside a global declaration\n\n ```ts\n declare global {\n interface HTMLElement {}\n }\n ```\n\n ## Options\n\n The rule provides several options that are detailed in the following subsections.\n\n ```json,options\n {\n \"options\": {\n \"strictCase\": false,\n \"requireAscii\": false,\n \"conventions\": [\n {\n \"selector\": {\n \"kind\": \"classMember\",\n \"modifiers\": [\"private\"]\n },\n \"match\": \"_(.+)\",\n \"formats\": [\"camelCase\"]\n }\n ]\n }\n }\n ```\n\n ### strictCase\n\n When this option is set to `true`, it forbids consecutive uppercase characters in [`camelCase`] and [`PascalCase`].\n\n **Default:** `true`\n\n For instance, `HTTPServer` or `aHTTPServer` are not permitted for `strictCase: true`.\n These names should be renamed to `HttpServer` and `aHttpServer`:\n\n ```json,options\n {\n \"options\": {\n \"strictCase\": true\n }\n }\n ```\n\n ```js,expect_diagnostic,use_options\n class HTTPServer {\n }\n ```\n\n When `strictCase` is set to `false`, consecutive uppercase characters are allowed.\n For example, `HTTPServer` and `aHTTPServer` would be considered valid then:\n\n ```json,options\n {\n \"options\": {\n \"strictCase\": false\n }\n }\n ```\n\n ```js,use_options\n class HTTPServer {\n }\n ```\n\n ### requireAscii\n\n When `true`, names must only consist of ASCII characters only,\n forbidding names like `café` or `안녕하세요` that include non-ASCII characters.\n\n When `requireAscii` is set to `false`, names may include non-ASCII characters.\n For example, `café` and `안녕하세요` would be considered valid then.\n\n **Default:** `true`\n\n ### conventions\n\n The `conventions` option allows applying custom conventions.\n The option takes an array of conventions.\n Every convention is an object that includes an optional `selector` and one or more requirements (`match` and `formats`).\n\n For example, you can enforce the use of [`CONSTANT_CASE`] for global `const` declarations:\n\n ```json,options\n {\n \"options\": {\n \"conventions\": [\n {\n \"selector\": {\n \"kind\": \"const\",\n \"scope\": \"global\"\n },\n \"formats\": [\"CONSTANT_CASE\"]\n }\n ]\n }\n }\n ```\n\n A selector describes which declarations the convention applies to.\n You can select a declaration based on several criteria:\n\n - `kind`: the kind of the declaration among:\n - `any` (default kind if the kind is unset)\n - `typeLike`: classes, enums, type aliases, and interfaces\n - `class`\n - `enum`\n - `enumMember`\n - `interface`\n - `typeAlias`\n - `function`: named function declarations and expressions\n - `namespaceLike`: TypeScript namespaces, import and export namespaces (`import * as namespace from`)\n - `namespace`: TypeScript namespaces\n - `importNamespace`\n - `exportNamespace`\n - `importAlias`: default imports and aliases of named imports\n - `exportAlias`: aliases of re-exported names\n - `variable`: const, let, using, and var declarations\n - `const`\n - `let`\n - `var`\n - `using`\n - `functionParameter`\n - `catchParameter`\n - `indexParameter`: parameters of index signatures\n - `typeParameter`: generic type parameter\n - `classMember`: class properties, parameter properties, methods, getters, and setters\n - `classProperty`: class properties, including parameter properties\n - `classMethod`\n - `classGetter`\n - `classSetter`\n - `objectLiteralMember`: literal object properties, methods, getters, and setters\n - `objectLiteralProperty`\n - `objectLiteralMethod`\n - `objectLiteralGetter`\n - `objectLiteralSetter`\n - `typeMember`: properties, methods, getters, and setters declared in type aliases and interfaces\n - `typeProperty`\n - `typeMethod`\n - `typeGetter`\n - `typeSetter`\n - `modifiers`: an array of modifiers among:\n - `abstract`: applies to class members and classes\n - `private`: applies to class members\n - `protected`: applies to class members\n - `readonly`: applies to class members and type members\n - `static`: applies to class members\n - `scope`: where the declaration appears. Allowed values:\n - `any`: anywhere (default value if the scope is unset)\n - `global`: the global scope (also includes the namespace scopes)\n\n For each declaration,\n the `conventions` array is traversed in-order until a selector selects the declaration.\n The requirements of the convention are so verified on the declaration.\n\n A convention must set at least one requirement among:\n\n - `match`: a regular expression that the name of the declaration must match.\n - `formats`: the string [case] that the name must follow.\n The supported cases are: [`PascalCase`], [`CONSTANT_CASE`], [`camelCase`], and [`snake_case`].\n\n If only `formats` is set, it's checked against the name of the declaration.\n In the following configuration, we require `static readonly` class properties to be in [`CONSTANT_CASE`].\n\n ```json,options\n {\n \"options\": {\n \"conventions\": [\n {\n \"selector\": {\n \"kind\": \"classProperty\",\n \"modifiers\": [\"static\", \"readonly\"]\n },\n \"formats\": [\"CONSTANT_CASE\"]\n }\n ]\n }\n }\n ```\n\n The following code is then reported by the rule:\n\n ```ts,use_options,expect_diagnostic\n class C {\n static readonly prop = 0;\n }\n ```\n\n A convention can make another one useless.\n In the following configuration, the second convention is useless because the first one always applies to class members, including class properties.\n You should always place first more specific conventions.\n\n ```json,options\n {\n \"options\": {\n \"conventions\": [\n {\n \"selector\": { \"kind\": \"classMember\" },\n \"formats\": [\"camelCase\"]\n },\n {\n \"selector\": { \"kind\": \"classProperty\" },\n \"formats\": [\"camelCase\", \"CONSTANT_CASE\"]\n }\n ]\n }\n }\n ```\n\n If only `match` is set and the regular expression has no capturing groups,\n then `match` is checked against the name of the declaration directly.\n In the following configuration, all variable names must have a minimum of 3 characters and a maximum of 20 characters.\n\n ```json,options\n {\n \"options\": {\n \"conventions\": [\n {\n \"selector\": { \"kind\": \"variable\" },\n \"match\": \".{3,20}\"\n }\n ]\n }\n }\n ```\n\n If both `match` and `formats` are set, then `formats` is checked against the first capture of the regular expression.\n Only the first capture is tested. Other captures are ignored.\n If nothing is captured, then `formats` is ignored.\n\n In the following example, we require that:\n\n - A private property starts with `_` and consists of at least two characters.\n - The captured name (the name without the leading `_`) is in [`camelCase`].\n\n ```json,options\n {\n \"options\": {\n \"conventions\": [\n {\n \"selector\": { \"kind\": \"classMember\", \"modifiers\": [\"private\"] },\n \"match\": \"_(.+)\",\n \"formats\": [\"camelCase\"]\n }\n ]\n }\n }\n ```\n\n If `match` is set and `formats` is unset, then the part of the name captured by the regular expression is forwarded to the next conventions of the array that selects the declaration.\n The following configuration has exactly the same effect as the previous one.\n The first convention applies to any private class member name.\n It stipulates that the name must have a leading underscore.\n The regular expression captures the part of the name without the leading underscore.\n Because `formats` is not set, the capture is forwarded to the next convention that applies to a private class member name.\n In our case, the next convention applies.\n The capture is then checked against `formats`.\n\n ```jsonc,options\n {\n \"options\": {\n \"conventions\": [\n {\n \"selector\": { \"kind\": \"classMember\", \"modifiers\": [\"private\"] },\n \"match\": \"_(.+)\"\n // We don't need to specify `formats` because the capture is forwarded to the next conventions.\n }, {\n \"selector\": { \"kind\": \"classMember\", \"modifiers\": [\"private\"] },\n \"formats\": [\"camelCase\"]\n }\n ]\n }\n }\n ```\n\n The forwarding has particularly useful to factorize some conventions.\n For example, the following configuration...\n\n ```jsonc,options\n {\n \"options\": {\n \"conventions\": [\n {\n \"selector\": { \"kind\": \"classMember\", \"modifiers\": [\"private\"] },\n \"match\": \"_(.+)\",\n \"formats\": [\"camelCase\"]\n }, {\n \"selector\": { \"kind\": \"classMember\" },\n \"formats\": [\"camelCase\"]\n }\n ]\n }\n }\n ```\n\n can be factorized to...\n\n ```jsonc,options\n {\n \"options\": {\n \"conventions\": [\n {\n \"selector\": { \"kind\": \"classMember\", \"modifiers\": [\"private\"] },\n \"match\": \"_(.+)\"\n }, {\n \"selector\": { \"kind\": \"classMember\" },\n \"formats\": [\"camelCase\"]\n }\n ]\n }\n }\n ```\n\n If a declaration is not selected or if a capture is forwarded while there are no more conventions,\n then the declaration name is verified against the default conventions.\n Because the default conventions already ensure that class members are in [\"camelCase\"],\n the previous example can be simplified to:\n\n ```jsonc,options\n {\n \"options\": {\n \"conventions\": [\n {\n \"selector\": { \"kind\": \"classMember\", \"modifiers\": [\"private\"] },\n \"match\": \"_(.+)\"\n // We don't need to specify `formats` because the capture is forwarded to the next conventions.\n }\n // default conventions\n ]\n }\n }\n ```\n\n If the capture is identical to the initial name (it is not a part of the initial name),\n then, leading and trailing underscore and dollar signs are trimmed before being checked against default conventions.\n In the previous example, the capture is a part of the name because `_` is not included in the capture, thus, no trimming is performed.\n\n You can reset all default conventions by adding a convention at the end of the array that accepts anything:\n\n ```jsonc,options\n {\n \"options\": {\n \"conventions\": [\n // your conventions\n // ...\n\n // Otherwise, accept anything\n {\n \"match\": \".*\"\n }\n ]\n }\n }\n ```\n\n Let's take a more complex example with the following conventions:\n\n 1. A variable name is `i`, `j`, or follows the next selected convention (convention (2)).\n 2. An identifier contains at least two characters and follow the next selected convention (the default convention).\n 3. A `private` class member name starts with an underscore `_` and the name without the underscore follows the next selected convention (convention (4) for some of them, and the default convention for others).\n 4. A `static readonly` class property name is in [`CONSTANT_CASE`].\n 5. A global constant is in [`CONSTANT_CASE`] and can be enclosed by double underscores or to be named `_SPECIAL_`.\n 6. An interface name starts with `I`, except for interfaces ending with `Error`, and is in [`PascalCase`].\n 7. All other names follow the default conventions\n\n ```jsonc,options\n {\n \"options\": {\n \"conventions\": [\n {\n \"selector\": {\n \"kind\": \"variable\"\n },\n \"match\": \"[ij]|(.*)\"\n },\n {\n \"match\": \"(.{2,})\"\n },\n {\n \"selector\": {\n \"kind\": \"classMember\",\n \"modifiers\": [\"private\"]\n },\n \"match\": \"_(.*)\"\n }, {\n \"selector\": {\n \"kind\": \"classProperty\",\n \"modifiers\": [\"static\", \"readonly\"]\n },\n \"formats\": [\"CONSTANT_CASE\"]\n }, {\n \"selector\": {\n \"kind\": \"const\",\n \"scope\": \"global\"\n },\n \"match\": \"__(.+)__|_SPECIAL_|(.+)\",\n \"formats\": [\"CONSTANT_CASE\"]\n }, {\n \"selector\": {\n \"kind\": \"interface\"\n },\n \"match\": \"I(.*)|(.*?)Error\",\n \"formats\": [\"PascalCase\"]\n }\n // default conventions\n ]\n }\n }\n ```\n\n Hers some examples:\n\n - A private class property named `_` is reported by the rule because it contains a single character.\n According to the second convention, the name should contain at least two characters.\n - A variable `a_variable` is reported by the rule because it doesn't respect the default convention that forbid variable names in [`snake_case`].\n The variable name is first verified against the first convention.\n It is forwarded to the second convention, which is also respected, because it is neither `i` nor `j`.\n The name is captured and is forwarded to the next convention.\n In our case, the next convention is the default one.\n\n ### Regular expression syntax\n\n The `match` option takes a regular expression that supports the following syntaxes:\n\n - Greedy quantifiers `*`, `?`, `+`, `{n}`, `{n,m}`, `{n,}`, `{m}`\n - Non-greedy quantifiers `*?`, `??`, `+?`, `{n}?`, `{n,m}?`, `{n,}?`, `{m}?`\n - Any character matcher `.`\n - Character classes `[a-z]`, `[xyz]`, `[^a-z]`\n - Alternations `|`\n - Capturing groups `()`\n - Non-capturing groups `(?:)`\n - Case-insensitive groups `(?i:)` and case-sensitive groups `(?-i:)`\n - A limited set of escaped characters including all special characters\n and regular string escape characters `\\f`, `\\n`, `\\r`, `\\t`, `\\v`.\n Note that you can also escape special characters using character classes.\n For example, `\\$` and `[$]` are two valid patterns that escape `$`.\n\n [case]: https://en.wikipedia.org/wiki/Naming_convention_(programming)#Examples_of_multiple-word_identifier_formats\n [`camelCase`]: https://en.wikipedia.org/wiki/Camel_case\n [`PascalCase`]: https://en.wikipedia.org/wiki/Camel_case\n [`CONSTANT_CASE`]: https://en.wikipedia.org/wiki/Snake_case\n [`snake_case`]: https://en.wikipedia.org/wiki/Snake_case\n"
+ "docs": " Enforce naming conventions for everything across a codebase.\n\n Enforcing [naming conventions](https://en.wikipedia.org/wiki/Naming_convention_(programming)) helps to keep the codebase consistent,\n and reduces overhead when thinking about the name [case] of a variable.\n\n The following section describes the default conventions enforced by the rule.\n You can also enforce custom conventions with the [rule options](#options).\n\n ## Naming conventions\n\n All names can be prefixed and suffixed with underscores `_` and dollar signs `$`.\n Unused variables with a name prefixed with `_` are completely ignored.\n This avoids conflicts with the `noUnusedVariables` rule.\n\n ### Variable and parameter names\n\n All variables and function parameters are in [`camelCase`] or [`PascalCase`].\n Catch parameters are in [`camelCase`].\n\n Additionally, global variables declared as `const` or `var` may be in [`CONSTANT_CASE`].\n Global variables are declared at module or script level.\n Variables declared in a TypeScript `namespace` are also considered global.\n\n ```js\n function f(param, _unusedParam) {\n let localValue = 0;\n try {\n /* ... */\n } catch (customError) {\n /* ... */\n }\n }\n\n export const A_CONSTANT = 5;\n\n let aVariable = 0;\n\n export namespace ns {\n export const ANOTHER_CONSTANT = \"\";\n }\n ```\n\n Examples of incorrect names:\n\n ```js,expect_diagnostic\n let a_value = 0;\n ```\n\n ```js,expect_diagnostic\n const fooYPosition = 0;\n ```\n\n ```js,expect_diagnostic\n function f(FIRST_PARAM) {}\n ```\n\n ### Function names\n\n - A `function` name is in [`camelCase`] or [`PascalCase`].\n - A global `function` can also be in `UPPERCASE`.\n This allows supporting the frameworks that require some function to use valid [HTTP method names](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods).\n\n ```jsx\n function trimString(s) { /*...*/ }\n\n function Component() {\n return ;\n }\n\n export function GET() { /*...*/ }\n ```\n\n ### TypeScript `enum` names\n\n A _TypeScript_ `enum` name is in [`PascalCase`].\n\n `enum` members are by default in [`PascalCase`].\n However, you can configure the [case] of `enum` members.\n See [options](#options) for more details.\n\n ```ts\n enum Status {\n Open,\n Close,\n }\n ```\n\n ### Classes\n\n - A class name is in [`PascalCase`].\n\n - Static property and static getter names are in [`camelCase`] or [`CONSTANT_CASE`].\n\n - Class property and method names are in [`camelCase`].\n\n ```js\n class Person {\n static MAX_FRIEND_COUNT = 256;\n\n static get SPECIAL_PERSON_INSTANCE() { /*...*/ }\n\n initializedProperty = 0;\n\n specialMethod() {}\n }\n ```\n\n ### TypeScript `type` aliases and `interface`\n\n - A `type` alias or an interface name are in [`PascalCase`].\n\n - Member names of a type are in [`camelCase`].\n\n - `readonly` property and getter names can also be in [`CONSTANT_CASE`].\n\n ```ts\n type Named = {\n readonly fullName: string;\n\n specialMethod(): void;\n };\n\n interface Named {\n readonly fullName: string;\n\n specialMethod(): void;\n }\n\n interface PersonConstructor {\n readonly MAX_FRIEND_COUNT: number;\n\n get SPECIAL_PERSON_INSTANCE(): Person;\n\n new(): Person;\n }\n ```\n\n Examples of an incorrect type alias:\n\n ```ts,expect_diagnostic\n type person = { fullName: string };\n ```\n\n ### Literal object member names\n\n - Literal object members are in [`camelCase`].\n\n ```js\n const alice = {\n fullName: \"Alice\",\n }\n ```\n\n Example of an incorrect name:\n\n ```js,expect_diagnostic\n const alice = {\n full_name: \"Alice\",\n }\n ```\n\n ### Import and export aliases and namespaces\n\n Import and export namespaces are in [`camelCase`] or [`PascalCase`].\n\n ```js\n import * as myLib from \"my-lib\";\n import * as Framework from \"framework\";\n\n export * as myLib from \"my-lib\";\n export * as Framework from \"framework\";\n ```\n\n `import` and `export` aliases are in [`camelCase`], [`PascalCase`], or [`CONSTANT_CASE`]:\n\n ```js\n import assert, {\n deepStrictEqual as deepEqual,\n AssertionError as AssertError\n } from \"node:assert\";\n ```\n\n Examples of an incorrect name:\n\n ```ts,expect_diagnostic\n import * as MY_LIB from \"my-lib\";\n ```\n\n ### TypeScript type parameter names\n\n A _TypeScript_ type parameter name is in [`PascalCase`].\n\n ```ts\n function id(value: Val): Val { /* ... */}\n ```\n\n ### TypeScript `namespace` names\n\n A _TypeScript_ `namespace` name is in [`camelCase`] or in [`PascalCase`].\n\n ```ts\n namespace mathExtra {\n /*...*/\n }\n\n namespace MathExtra {\n /*...*/\n }\n ```\n\n ## Ignored declarations\n\n Note that some declarations are always ignored.\n You cannot apply a convention to them.\n This is the case for:\n\n - Member names that are not identifiers\n\n ```js\n class C {\n [\"not an identifier\"]() {}\n }\n ```\n\n - Named imports\n\n ```js\n import { an_IMPORT } from \"mod\"\n ```\n\n - Destructured object properties\n\n ```js\n const { destructed_PROP } = obj;\n ```\n\n - Class members marked with `override`:\n\n ```ts\n class C extends B {\n override overridden_METHOD() {}\n }\n ```\n\n - Declarations inside an external TypeScript module\n\n ```ts\n declare module \"myExternalModule\" {\n export interface my_INTERFACE {}\n }\n ```\n\n - Declarations inside a global declaration\n\n ```ts\n declare global {\n interface HTMLElement {}\n }\n ```\n\n ## Options\n\n The rule provides several options that are detailed in the following subsections.\n\n ```json,options\n {\n \"options\": {\n \"strictCase\": false,\n \"requireAscii\": false,\n \"conventions\": [\n {\n \"selector\": {\n \"kind\": \"classMember\",\n \"modifiers\": [\"private\"]\n },\n \"match\": \"_(.+)\",\n \"formats\": [\"camelCase\"]\n }\n ]\n }\n }\n ```\n\n ### strictCase\n\n When this option is set to `true`, it forbids consecutive uppercase characters in [`camelCase`] and [`PascalCase`].\n\n **Default:** `true`\n\n For instance, `HTTPServer` or `aHTTPServer` are not permitted for `strictCase: true`.\n These names should be renamed to `HttpServer` and `aHttpServer`:\n\n ```json,options\n {\n \"options\": {\n \"strictCase\": true\n }\n }\n ```\n\n ```js,expect_diagnostic,use_options\n class HTTPServer {\n }\n ```\n\n When `strictCase` is set to `false`, consecutive uppercase characters are allowed.\n For example, `HTTPServer` and `aHTTPServer` would be considered valid then:\n\n ```json,options\n {\n \"options\": {\n \"strictCase\": false\n }\n }\n ```\n\n ```js,use_options\n class HTTPServer {\n }\n ```\n\n ### requireAscii\n\n When `true`, names must only consist of ASCII characters only,\n forbidding names like `café` or `안녕하세요` that include non-ASCII characters.\n\n When `requireAscii` is set to `false`, names may include non-ASCII characters.\n For example, `café` and `안녕하세요` would be considered valid then.\n\n **Default:** `true`\n\n ### conventions\n\n The `conventions` option allows applying custom conventions.\n The option takes an array of conventions.\n Every convention is an object that includes an optional `selector` and one or more requirements (`match` and `formats`).\n\n For example, you can enforce the use of [`CONSTANT_CASE`] for global `const` declarations:\n\n ```json,options\n {\n \"options\": {\n \"conventions\": [\n {\n \"selector\": {\n \"kind\": \"const\",\n \"scope\": \"global\"\n },\n \"formats\": [\"CONSTANT_CASE\"]\n }\n ]\n }\n }\n ```\n\n A selector describes which declarations the convention applies to.\n You can select a declaration based on several criteria:\n\n - `kind`: the kind of the declaration among:\n - `any` (default kind if the kind is unset)\n - `typeLike`: classes, enums, type aliases, and interfaces\n - `class`\n - `enum`\n - `enumMember`\n - `interface`\n - `typeAlias`\n - `function`: named function declarations and expressions\n - `namespaceLike`: TypeScript namespaces, import and export namespaces (`import * as namespace from`)\n - `namespace`: TypeScript namespaces\n - `importNamespace`\n - `exportNamespace`\n - `importAlias`: default imports and aliases of named imports\n - `exportAlias`: aliases of re-exported names\n - `variable`: const, let, using, and var declarations\n - `const`\n - `let`\n - `var`\n - `using`\n - `functionParameter`\n - `catchParameter`\n - `indexParameter`: parameters of index signatures\n - `typeParameter`: generic type parameter\n - `classMember`: class properties, parameter properties, methods, getters, and setters\n - `classProperty`: class properties, including parameter properties\n - `classMethod`\n - `classGetter`\n - `classSetter`\n - `objectLiteralMember`: literal object properties, methods, getters, and setters (you might want to duplicate the convention for `typeMember`)\n - `objectLiteralProperty`\n - `objectLiteralMethod`\n - `objectLiteralGetter`\n - `objectLiteralSetter`\n - `typeMember`: properties, methods, getters, and setters declared in type aliases and interfaces\n - `typeProperty`\n - `typeMethod`\n - `typeGetter`\n - `typeSetter`\n - `modifiers`: an array of modifiers among:\n - `abstract`: applies to class members and classes\n - `private`: applies to class members\n - `protected`: applies to class members\n - `readonly`: applies to class members and type members\n - `static`: applies to class members\n - `scope`: where the declaration appears. Allowed values:\n - `any`: anywhere (default value if the scope is unset)\n - `global`: the global scope (also includes the namespace scopes)\n\n For each declaration,\n the `conventions` array is traversed in-order until a selector selects the declaration.\n The requirements of the convention are so verified on the declaration.\n\n A convention must set at least one requirement among:\n\n - `match`: a regular expression that the name of the declaration must match.\n - `formats`: the string [case] that the name must follow.\n The supported cases are: [`PascalCase`], [`CONSTANT_CASE`], [`camelCase`], and [`snake_case`].\n\n If only `formats` is set, it's checked against the name of the declaration.\n In the following configuration, we require `static readonly` class properties to be in [`CONSTANT_CASE`].\n\n ```json,options\n {\n \"options\": {\n \"conventions\": [\n {\n \"selector\": {\n \"kind\": \"classProperty\",\n \"modifiers\": [\"static\", \"readonly\"]\n },\n \"formats\": [\"CONSTANT_CASE\"]\n }\n ]\n }\n }\n ```\n\n The following code is then reported by the rule:\n\n ```ts,use_options,expect_diagnostic\n class C {\n static readonly prop = 0;\n }\n ```\n\n A convention can make another one useless.\n In the following configuration, the second convention is useless because the first one always applies to class members, including class properties.\n You should always place first more specific conventions.\n\n ```json,options\n {\n \"options\": {\n \"conventions\": [\n {\n \"selector\": { \"kind\": \"classMember\" },\n \"formats\": [\"camelCase\"]\n },\n {\n \"selector\": { \"kind\": \"classProperty\" },\n \"formats\": [\"camelCase\", \"CONSTANT_CASE\"]\n }\n ]\n }\n }\n ```\n\n If only `match` is set and the regular expression has no capturing groups,\n then `match` is checked against the name of the declaration directly.\n In the following configuration, all variable names must have a minimum of 3 characters and a maximum of 20 characters.\n\n ```json,options\n {\n \"options\": {\n \"conventions\": [\n {\n \"selector\": { \"kind\": \"variable\" },\n \"match\": \".{3,20}\"\n }\n ]\n }\n }\n ```\n\n If both `match` and `formats` are set, then `formats` is checked against the first capture of the regular expression.\n Only the first capture is tested. Other captures are ignored.\n If nothing is captured, then `formats` is ignored.\n\n In the following example, we require that:\n\n - A private property starts with `_` and consists of at least two characters.\n - The captured name (the name without the leading `_`) is in [`camelCase`].\n\n ```json,options\n {\n \"options\": {\n \"conventions\": [\n {\n \"selector\": { \"kind\": \"classMember\", \"modifiers\": [\"private\"] },\n \"match\": \"_(.+)\",\n \"formats\": [\"camelCase\"]\n }\n ]\n }\n }\n ```\n\n If `match` is set and `formats` is unset, then the part of the name captured by the regular expression is forwarded to the next conventions of the array that selects the declaration.\n The following configuration has exactly the same effect as the previous one.\n The first convention applies to any private class member name.\n It stipulates that the name must have a leading underscore.\n The regular expression captures the part of the name without the leading underscore.\n Because `formats` is not set, the capture is forwarded to the next convention that applies to a private class member name.\n In our case, the next convention applies.\n The capture is then checked against `formats`.\n\n ```jsonc,options\n {\n \"options\": {\n \"conventions\": [\n {\n \"selector\": { \"kind\": \"classMember\", \"modifiers\": [\"private\"] },\n \"match\": \"_(.+)\"\n // We don't need to specify `formats` because the capture is forwarded to the next conventions.\n }, {\n \"selector\": { \"kind\": \"classMember\", \"modifiers\": [\"private\"] },\n \"formats\": [\"camelCase\"]\n }\n ]\n }\n }\n ```\n\n The forwarding has particularly useful to factorize some conventions.\n For example, the following configuration...\n\n ```jsonc,options\n {\n \"options\": {\n \"conventions\": [\n {\n \"selector\": { \"kind\": \"classMember\", \"modifiers\": [\"private\"] },\n \"match\": \"_(.+)\",\n \"formats\": [\"camelCase\"]\n }, {\n \"selector\": { \"kind\": \"classMember\" },\n \"formats\": [\"camelCase\"]\n }\n ]\n }\n }\n ```\n\n can be factorized to...\n\n ```jsonc,options\n {\n \"options\": {\n \"conventions\": [\n {\n \"selector\": { \"kind\": \"classMember\", \"modifiers\": [\"private\"] },\n \"match\": \"_(.+)\"\n }, {\n \"selector\": { \"kind\": \"classMember\" },\n \"formats\": [\"camelCase\"]\n }\n ]\n }\n }\n ```\n\n If a declaration is not selected or if a capture is forwarded while there are no more conventions,\n then the declaration name is verified against the default conventions.\n Because the default conventions already ensure that class members are in [\"camelCase\"],\n the previous example can be simplified to:\n\n ```jsonc,options\n {\n \"options\": {\n \"conventions\": [\n {\n \"selector\": { \"kind\": \"classMember\", \"modifiers\": [\"private\"] },\n \"match\": \"_(.+)\"\n // We don't need to specify `formats` because the capture is forwarded to the next conventions.\n }\n // default conventions\n ]\n }\n }\n ```\n\n If the capture is identical to the initial name (it is not a part of the initial name),\n then, leading and trailing underscore and dollar signs are trimmed before being checked against default conventions.\n In the previous example, the capture is a part of the name because `_` is not included in the capture, thus, no trimming is performed.\n\n You can reset all default conventions by adding a convention at the end of the array that accepts anything:\n\n ```jsonc,options\n {\n \"options\": {\n \"conventions\": [\n // your conventions\n // ...\n\n // Otherwise, accept anything\n {\n \"match\": \".*\"\n }\n ]\n }\n }\n ```\n\n Let's take a more complex example with the following conventions:\n\n 1. A variable name is `i`, `j`, or follows the next selected convention (convention (2)).\n 2. An identifier contains at least two characters and follow the next selected convention (the default convention).\n 3. A `private` class member name starts with an underscore `_` and the name without the underscore follows the next selected convention (convention (4) for some of them, and the default convention for others).\n 4. A `static readonly` class property name is in [`CONSTANT_CASE`].\n 5. A global constant is in [`CONSTANT_CASE`] and can be enclosed by double underscores or to be named `_SPECIAL_`.\n 6. An interface name starts with `I`, except for interfaces ending with `Error`, and is in [`PascalCase`].\n 7. All other names follow the default conventions\n\n ```jsonc,options\n {\n \"options\": {\n \"conventions\": [\n {\n \"selector\": {\n \"kind\": \"variable\"\n },\n \"match\": \"[ij]|(.*)\"\n },\n {\n \"match\": \"(.{2,})\"\n },\n {\n \"selector\": {\n \"kind\": \"classMember\",\n \"modifiers\": [\"private\"]\n },\n \"match\": \"_(.*)\"\n }, {\n \"selector\": {\n \"kind\": \"classProperty\",\n \"modifiers\": [\"static\", \"readonly\"]\n },\n \"formats\": [\"CONSTANT_CASE\"]\n }, {\n \"selector\": {\n \"kind\": \"const\",\n \"scope\": \"global\"\n },\n \"match\": \"__(.+)__|_SPECIAL_|(.+)\",\n \"formats\": [\"CONSTANT_CASE\"]\n }, {\n \"selector\": {\n \"kind\": \"interface\"\n },\n \"match\": \"I(.*)|(.*?)Error\",\n \"formats\": [\"PascalCase\"]\n }\n // default conventions\n ]\n }\n }\n ```\n\n Hers some examples:\n\n - A private class property named `_` is reported by the rule because it contains a single character.\n According to the second convention, the name should contain at least two characters.\n - A variable `a_variable` is reported by the rule because it doesn't respect the default convention that forbid variable names in [`snake_case`].\n The variable name is first verified against the first convention.\n It is forwarded to the second convention, which is also respected, because it is neither `i` nor `j`.\n The name is captured and is forwarded to the next convention.\n In our case, the next convention is the default one.\n\n ### Regular expression syntax\n\n The `match` option takes a regular expression that supports the following syntaxes:\n\n - Greedy quantifiers `*`, `?`, `+`, `{n}`, `{n,m}`, `{n,}`, `{m}`\n - Non-greedy quantifiers `*?`, `??`, `+?`, `{n}?`, `{n,m}?`, `{n,}?`, `{m}?`\n - Any character matcher `.`\n - Character classes `[a-z]`, `[xyz]`, `[^a-z]`\n - Alternations `|`\n - Capturing groups `()`\n - Non-capturing groups `(?:)`\n - Case-insensitive groups `(?i:)` and case-sensitive groups `(?-i:)`\n - A limited set of escaped characters including all special characters\n and regular string escape characters `\\f`, `\\n`, `\\r`, `\\t`, `\\v`.\n Note that you can also escape special characters using character classes.\n For example, `\\$` and `[$]` are two valid patterns that escape `$`.\n\n [case]: https://en.wikipedia.org/wiki/Naming_convention_(programming)#Examples_of_multiple-word_identifier_formats\n [`camelCase`]: https://en.wikipedia.org/wiki/Camel_case\n [`PascalCase`]: https://en.wikipedia.org/wiki/Camel_case\n [`CONSTANT_CASE`]: https://en.wikipedia.org/wiki/Snake_case\n [`snake_case`]: https://en.wikipedia.org/wiki/Snake_case\n"
},
"useReadonlyClassProperties": {
"deprecated": false,
@@ -7932,7 +8015,7 @@ export function GET() {
}
}
},
- "numberOrRules": 457
+ "numberOrRules": 462
},
"syntax": {
"languages": {
diff --git a/src/pages/metadata/schema.json.js b/src/pages/metadata/schema.json.js
index 4da26e032..b86929119 100644
--- a/src/pages/metadata/schema.json.js
+++ b/src/pages/metadata/schema.json.js
@@ -216,6 +216,13 @@ export function GET() {
"additionalProperties": false,
"required": ["eslintPerfectionist"]
},
+ {
+ "description": "Rules from [Eslint Plugin Promise](https://github.com/eslint-community/eslint-plugin-promise)",
+ "type": "object",
+ "properties": { "eslintPromise": { "type": "string" } },
+ "additionalProperties": false,
+ "required": ["eslintPromise"]
+ },
{
"description": "Rules from [Eslint Plugin Qwik](https://github.com/QwikDev/qwik)",
"type": "object",
diff --git a/src/playground/generated/lintRules.ts b/src/playground/generated/lintRules.ts
index 6fb753312..5922f784f 100644
--- a/src/playground/generated/lintRules.ts
+++ b/src/playground/generated/lintRules.ts
@@ -193,10 +193,12 @@ export const LINT_RULES = {
noMisusedPromises: "noMisusedPromises",
noMultiAssign: "noMultiAssign",
noMultiStr: "noMultiStr",
+ noNestedPromises: "noNestedPromises",
noNextAsyncClientComponent: "noNextAsyncClientComponent",
noParametersOnlyUsedInRecursion: "noParametersOnlyUsedInRecursion",
noProto: "noProto",
noReactForwardRef: "noReactForwardRef",
+ noRedundantDefaultExport: "noRedundantDefaultExport",
noReturnAssign: "noReturnAssign",
noRootType: "noRootType",
noScriptUrl: "noScriptUrl",
@@ -209,6 +211,7 @@ export const LINT_RULES = {
noUnresolvedImports: "noUnresolvedImports",
noUnusedExpressions: "noUnusedExpressions",
noUselessCatchBinding: "noUselessCatchBinding",
+ noUselessReturn: "noUselessReturn",
noUselessUndefined: "noUselessUndefined",
noVueArrowFuncInWatch: "noVueArrowFuncInWatch",
noVueDataObjectDeclaration: "noVueDataObjectDeclaration",
@@ -223,12 +226,14 @@ export const LINT_RULES = {
useConsistentArrowReturn: "useConsistentArrowReturn",
useConsistentEnumValueType: "useConsistentEnumValueType",
useConsistentGraphqlDescriptions: "useConsistentGraphqlDescriptions",
+ useConsistentMethodSignatures: "useConsistentMethodSignatures",
useDeprecatedDate: "useDeprecatedDate",
useDestructuring: "useDestructuring",
useErrorCause: "useErrorCause",
useExhaustiveSwitchCases: "useExhaustiveSwitchCases",
useExplicitType: "useExplicitType",
useFind: "useFind",
+ useGlobalThis: "useGlobalThis",
useInlineScriptId: "useInlineScriptId",
useInputName: "useInputName",
useLoneAnonymousOperation: "useLoneAnonymousOperation",