.ignore`.
+Notez qu’ils n’écrasent pas les `files.include` et `files.ignore` globaux.
+`files.include` et `files.ignore` s’appliquent en premier avant les `include` et `ignore` d’un outil.
+
+Prenons la configuration suivante :
+
+```json title="biome.json"
+{
+ "files": {
+ "include": ["src/**/*.js", "test/**/*.js"],
+ "ignore": ["**/*.min.js"],
+ },
+ "linter": {
+ "ignore": ["test"]
+ }
+}
+```
+
+Et exécutons la commande suivante :
+
+```shell
+biome format test/
+```
+
+La commande formatera les fichiers du répertoire `test` qui se terminent par l’extension `.js` et pas par l’extension `.min.js`.
+Les fichiers de `src` ne sont pas formatés parce que le répertoire n’est pas listé en ligne de commande.
+
+Si nous exécutons la commande suivante, aucun fichier n’est analysé parce que le répertoire `test` est explicitement ignoré par l’outil de linting.
+
+```shell
+biome lint test/
+```
+
+Biome résoud les globs par rapport au répertoire de travail.
+Le répertoire de travail est le répertoire où vous exécutez habituellement une commande en ligne de commande,
+ce qui veut dire que vous devez faire **particulièrement attention** quand le fichier de configuration est placé dans un répertoire différent de celui où vous exécutez votre commande.
+Dans le cas d’un éditeur (LSP), le répertoire de travail est le répertoire racine de votre projet.
+
+Prenons un projet qui contient deux répertoires `backend/` et `frontend/`, ainsi que le fichier de configuration de Biome que nous avons présenté auparavant.
+Dans le réperoire `frontend/`, un `package.json` spécifie un script `format` qui exécute l’outil de formatage de Biome.
+
+
+- backend
+ - ...
+- biome.json
+- frontend
+ - package.json
+ - src
+ - ...
+ - test
+ - ...
+
+
+```json title="frontend/package.json"
+{
+ "name": "frontend-project",
+ "scripts": {
+ "format": "biome format --write ./"
+ }
+}
+```
+
+Quand vous exécutez le script `format` de `frontend/package.json`,
+le répertoire de travail résolu par ce script sera `frontend/`.
+Les globs `src/**/*.js` et `test/**/*.js` auront pour répertoire de « base » `frontend/`.
+Ainsi, seuls les fichiers dans `frontend/src/` et `frontend/test/` seront formatés.
+
+```json title="biome.json"
+{
+ "files": {
+ "include": ["src/**/*.js", "src/**/*.ts"],
+ "ignore": ["test"]
+ },
+ "formatter": {
+ "indentStyle": "space"
+ }
+}
+```
+
+:::caution
+`ignore` et `include` dans `overrides` ont une sémantique **différente :**
+- pour `ignore` : si un fichier correspond aux globs, **ne pas faire appliquer** la configuration dans cet écrasement et continuer à faire appliquer les écrasements suivants ;
+- pour `include` : si un fichier correspond aux globs, **faire appliquer** la configuration dans cet écrasement et continuer à faire appliquer les écrasements suivants.
+:::
+
+:::note
+Par défaut, Biome ignore toujours certains fichiers réputés être des **fichiers protégés,**
+ce qui veut dire que jamais aucun diagnostic ne sera émis par Biome pour ces fichiers.
+En ce moment, les fichiers suivants sont protégés :
+
+- `composer.lock`
+- `npm-shrinkwrap.json`
+- `package-lock.json`
+- `yarn.lock`
+:::
+
+:::note
+Vous pouvez également [ignorer les fichiers ignorés par votre VCS](/fr/guides/integrate-in-vcs#use-the-ignore-file).
+:::
+
+
+## Fichiers bien connus
+
+Voici quelques fichiers bien connus que nous traitons spécifiquement, en nous basant sur leur nom plutôt que sur leur extension.
+Actuellement, les fichiers bien connus ne sont que des fichiers semblables à du JSON, mais nous pourrons élargir la liste pour y inclure d’autres types quand nous prendrons en charge de nouveaux analyseurs.
+
+Les fichiers suivants sont analysés comme des fichiers `JSON` avec les deux options `json.parser.allowComments` et `json.parser.allowTrailingCommas` définies à `false`.
+
+- `.all-contributorsrc`
+- `.arcconfig`
+- `.auto-changelog`
+- `.bowerrc`
+- `.c8rc`
+- `.htmlhintrc`
+- `.imgbotconfig`
+- `.jslintrc`
+- `.nycrc`
+- `.tern-config`
+- `.tern-project`
+- `.vuerc`
+- `.watchmanconfig`
+- `mcmod.info`
+
+Les fichiers suivants sont analysés comme des fichiers `JSON` avec l’option `json.parser.allowComments` définie à `true`, mais avec l’option `json.parser.allowTrailingCommas` définie à `false`. C’est parce que les outils traitant ces fichiers ne peuvent qu’enlever les commentaires.
+
+- `.ember-cli`
+- `.eslintrc.json`
+- `.jscsrc`
+- `.jshintrc`
+- `tslint.json`
+- `turbo.json`
+
+Les fichiers suivants sont analysés comme des fichiers `JSON` avec les options `json.parser.allowComments` et `json.parser.allowTrailingCommas` définies à `true`. C’est parce que les outils traitant ces fichiers sont conçus pour tenir compte de tels réglages.
+
+- `.babelrc`
+- `.babelrc.json`
+- `.devcontainer.json`
+- `.hintrc`
+- `.hintrc.json`
+- `.swcrc`
+- `api-documenter.json`
+- `api-extractor.json`
+- `babel.config.json`
+- `deno.json`
+- `devcontainer.json`
+- `dprint.json`
+- `jsconfig.json`
+- `jsr.json`
+- `language-configuration.json`
+- `tsconfig.json`
+- `typedoc.json`
+- `typescript.json`
+
+
+## La syntaxe glob expliquée
+
+Un motif glob spécifie un ensemble de noms de fichier.
+Biome prend en charge les globs suivants :
+
+- `*` correspond à zéro ou plusieurs caractères. Il ne peut pas correspondre au séparateur de chemin `/`.
+- `**` correspond à des répertoires et à des fichiers de manière récursive.
+ Cette séquence **doit** former un seul composant de chemin,
+ donc `**a` et `b**` sont tous les deux invalides et provoqueront une erreur.
+ Une séquence de plus de deux caractères `*` consécutifs est également invalide.
+- `[...]` correspond à n’importe quel caractère se trouvant entre les crochets.
+ Des plages de caractères peuvent également être spécifiées, selon leur ordre dans Unicode, donc
+ `[0-9]`, par exemple, spécifie tout caractère compris entre 0 et 9.
+- `[!...]` est la négation de `[...]`, c’est-à-dire qu’il correspond à tout caractère ne se trouvant **pas** entre les crochets.
+
+Quelques exemples :
+
+- `dist/**` correspond au réperoire `dist` et à tous les fichiers dans ce réperoire.
+- `**/test/**` correspond à tous les fichiers de tout répertoire appelé `test`, indépendamment de son emplacement. Par exemple, `dist/test`, `src/test`.
+- `**/*.js` correspond à tous les fichiers se terminant par l’extension `.js` dans tous les répertoires.
+
+Biome utilise une librairie glob qui traite tous les globs comme s’ils avaient un préfixe `**/`.
+Ce qui veut dire que `src/**/*.js` et `**/src/**/*.js` sont traités de manière identique.
+Ils correspondent à la fois à `src/file.js` et à `test/src/file.js`.
+
+:::caution
+Ces motifs peuvent être utilisés dans un fichier de configuration de Biome.
+Les motifs glob utilisés en ligne de commande ne sont pas interprétés par Biome.
+Ils sont développés par votre shell.
+Certains shells ne prennent pas en charge le glob récursif `**`.
+:::
diff --git a/src/content/docs/linter/rules/index.mdx b/src/content/docs/linter/rules/index.mdx
index 26e41cd2e..aceadb247 100644
--- a/src/content/docs/linter/rules/index.mdx
+++ b/src/content/docs/linter/rules/index.mdx
@@ -176,8 +176,8 @@ New rules that are still under development.
Nursery rules require exp
| [noHeadElement](/linter/rules/no-head-element) | Prevent usage of `` element in a Next.js project. | |
| [noHeadImportInDocument](/linter/rules/no-head-import-in-document) | Prevent using the `next/head` module in `pages/_document.js` on Next.js projects. | |
| [noImgElement](/linter/rules/no-img-element) | Prevent usage of `![]()
` element in a Next.js project. | |
-| [noIrregularWhitespace](/linter/rules/no-irregular-whitespace) | Disallows the use of irregular whitespace characters. | |
| [noIrregularWhitespace](/linter/rules/no-irregular-whitespace) | Disallows the use of irregular whitespace characters. | |
+| [noIrregularWhitespace](/linter/rules/no-irregular-whitespace) | Disallows the use of irregular whitespace characters. | |
| [noMissingVarFunction](/linter/rules/no-missing-var-function) | Disallow missing var function for css variables. | |
| [noNestedTernary](/linter/rules/no-nested-ternary) | Disallow nested ternary expressions. | |
| [noOctalEscape](/linter/rules/no-octal-escape) | Disallow octal escape sequences in string literals | |
diff --git a/src/content/docs/linter/rules/no-unused-variables.mdx b/src/content/docs/linter/rules/no-unused-variables.mdx
index 5fc445719..e0fae6d92 100644
--- a/src/content/docs/linter/rules/no-unused-variables.mdx
+++ b/src/content/docs/linter/rules/no-unused-variables.mdx
@@ -33,9 +33,11 @@ This rule won't report unused imports.
If you want to report unused imports,
enable [noUnusedImports](https://biomejs.dev/linter/rules/no-unused-imports/).
-From `v1.9.0`, the rule won't check unused function parameters any more.
+:::caution
+From `v2.0.0`, the rule won't check unused function parameters any more.
If you want to report unused function parameters,
enable [noUnusedFunctionParameters](https://biomejs.dev/linter/rules/no-unused-function-parameters/).
+:::
## Examples
diff --git a/src/content/docs/linter/rules/use-explicit-type.mdx b/src/content/docs/linter/rules/use-explicit-type.mdx
index df04c2ff8..57d5788a2 100644
--- a/src/content/docs/linter/rules/use-explicit-type.mdx
+++ b/src/content/docs/linter/rules/use-explicit-type.mdx
@@ -41,7 +41,7 @@ function test() {
}
```
-code-block.ts:1:1 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
> 1 │ // Should indicate that no value is returned (void)
│ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 2 │ function test() {
│ ^^^^^^^^^^^^^
3 │ return;
4 │ }
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
+code-block.ts:1:1 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
> 1 │ // Should indicate that no value is returned (void)
│ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 2 │ function test() {
│ ^^^^^^^^^^^^^
3 │ return;
4 │ }
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
```ts
// Should indicate that a number is returned
@@ -50,14 +50,14 @@ var fn = function () {
};
```
-code-block.ts:2:10 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
1 │ // Should indicate that a number is returned
> 2 │ var fn = function () {
│ ^^^^^^^^^^^^^
> 3 │ return 1;
> 4 │ };
│ ^
5 │
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
+code-block.ts:2:10 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
1 │ // Should indicate that a number is returned
> 2 │ var fn = function () {
│ ^^^^^^^^^^^^^
> 3 │ return 1;
> 4 │ };
│ ^
5 │
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
```ts
// Should indicate that a string is returned
var arrowFn = () => 'test';
```
-code-block.ts:2:15 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
1 │ // Should indicate that a string is returned
> 2 │ var arrowFn = () => 'test';
│ ^^^^^^^^^^^^
3 │
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
+code-block.ts:2:15 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
1 │ // Should indicate that a string is returned
> 2 │ var arrowFn = () => 'test';
│ ^^^^^^^^^^^^
3 │
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
```ts
class Test {
@@ -68,7 +68,7 @@ class Test {
}
```
-code-block.ts:3:3 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
1 │ class Test {
2 │ // Should indicate that no value is returned (void)
> 3 │ method() {
│ ^^^^^^^^^^
> 4 │ return;
> 5 │ }
│ ^
6 │ }
7 │
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
+code-block.ts:3:3 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
1 │ class Test {
2 │ // Should indicate that no value is returned (void)
> 3 │ method() {
│ ^^^^^^^^^^
> 4 │ return;
> 5 │ }
│ ^
6 │ }
7 │
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
```ts
// Should indicate that no value is returned (void)
@@ -77,14 +77,14 @@ function test(a: number) {
}
```
-code-block.ts:1:1 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
> 1 │ // Should indicate that no value is returned (void)
│ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 2 │ function test(a: number) {
│ ^^^^^^^^^^^^^
3 │ a += 1;
4 │ }
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
+code-block.ts:1:1 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
> 1 │ // Should indicate that no value is returned (void)
│ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 2 │ function test(a: number) {
│ ^^^^^^^^^^^^^
3 │ a += 1;
4 │ }
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
```ts
// Should use const assertions
const func = (value: number) => ({ type: 'X', value }) as any;
```
-code-block.ts:2:14 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
1 │ // Should use const assertions
> 2 │ const func = (value: number) => ({ type: 'X', value }) as any;
│ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3 │
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
+code-block.ts:2:14 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
1 │ // Should use const assertions
> 2 │ const func = (value: number) => ({ type: 'X', value }) as any;
│ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3 │
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
The following pattern is considered incorrect code for a higher-order function, as the returned function does not specify a return type:
@@ -92,7 +92,7 @@ The following pattern is considered incorrect code for a higher-order function,
const arrowFn = () => () => {};
```
-code-block.ts:1:23 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
> 1 │ const arrowFn = () => () => {};
│ ^^^^^^^^
2 │
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
+code-block.ts:1:23 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
> 1 │ const arrowFn = () => () => {};
│ ^^^^^^^^
2 │
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
```ts
const arrowFn = () => {
@@ -100,7 +100,7 @@ const arrowFn = () => {
}
```
-code-block.ts:2:10 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
1 │ const arrowFn = () => {
> 2 │ return () => { };
│ ^^^^^^^^^
3 │ }
4 │
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
+code-block.ts:2:10 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
1 │ const arrowFn = () => {
> 2 │ return () => { };
│ ^^^^^^^^^
3 │ }
4 │
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
The following pattern is considered incorrect code for a higher-order function because the function body contains multiple statements. We only check whether the first statement is a function return.
@@ -114,7 +114,7 @@ function f() {
}
```
-code-block.ts:1:1 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
> 1 │ // A function has multiple statements in the body
│ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 2 │ function f() {
│ ^^^^^^^^^^
3 │ if (x) {
4 │ return 0;
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
+code-block.ts:1:1 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
> 1 │ // A function has multiple statements in the body
│ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 2 │ function f() {
│ ^^^^^^^^^^
3 │ if (x) {
4 │ return 0;
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
```ts
// A function has multiple statements in the body
@@ -126,7 +126,7 @@ function f() {
}
```
-code-block.ts:1:1 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
> 1 │ // A function has multiple statements in the body
│ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 2 │ function f() {
│ ^^^^^^^^^^
3 │ let str = "test";
4 │ return (): string => {
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
+code-block.ts:1:1 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
> 1 │ // A function has multiple statements in the body
│ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 2 │ function f() {
│ ^^^^^^^^^^
3 │ let str = "test";
4 │ return (): string => {
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
The following pattern is considered incorrect code for an interface method without a return type:
@@ -136,7 +136,7 @@ interface Array {
}
```
-code-block.ts:2:3 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
1 │ interface Array<Type> {
> 2 │ method();
│ ^^^^^^^^^
3 │ }
4 │
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
+code-block.ts:2:3 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
1 │ interface Array<Type> {
> 2 │ method();
│ ^^^^^^^^^
3 │ }
4 │
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
The following pattern is considered incorrect code for a type declaration of a function without a return type:
@@ -147,7 +147,7 @@ type MyObject = {
};
```
-code-block.ts:2:3 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
1 │ type MyObject = {
> 2 │ (input: string);
│ ^^^^^^^^^^^^^^^^
3 │ propertyName: string;
4 │ };
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
+code-block.ts:2:3 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
1 │ type MyObject = {
> 2 │ (input: string);
│ ^^^^^^^^^^^^^^^^
3 │ propertyName: string;
4 │ };
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
The following pattern is considered incorrect code for an abstract class method without a return type:
@@ -157,7 +157,7 @@ abstract class MyClass {
}
```
-code-block.ts:2:3 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
1 │ abstract class MyClass {
> 2 │ public abstract method();
│ ^^^^^^^^^^^^^^^^^^^^^^^^^
3 │ }
4 │
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
+code-block.ts:2:3 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
1 │ abstract class MyClass {
> 2 │ public abstract method();
│ ^^^^^^^^^^^^^^^^^^^^^^^^^
3 │ }
4 │
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
The following pattern is considered incorrect code for an abstract class getter without a return type:
@@ -167,7 +167,7 @@ abstract class P {
}
```
-code-block.ts:2:3 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
1 │ abstract class P<T> {
> 2 │ abstract get poke();
│ ^^^^^^^^^^^^^^^^^^^^
3 │ }
4 │
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
+code-block.ts:2:3 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
1 │ abstract class P<T> {
> 2 │ abstract get poke();
│ ^^^^^^^^^^^^^^^^^^^^
3 │ }
4 │
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
The following pattern is considered incorrect code for a function declaration in a namespace without a return type:
@@ -177,7 +177,7 @@ declare namespace myLib {
}
```
-code-block.ts:2:3 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
1 │ declare namespace myLib {
> 2 │ function makeGreeting(s: string);
│ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3 │ }
4 │
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
+code-block.ts:2:3 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
1 │ declare namespace myLib {
> 2 │ function makeGreeting(s: string);
│ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3 │ }
4 │
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
The following pattern is considered incorrect code for a module function export without a return type:
@@ -187,7 +187,7 @@ declare module "foo" {
}
```
-code-block.ts:2:18 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
1 │ declare module "foo" {
> 2 │ export default function bar();
│ ^^^^^^^^^^^^^^^
3 │ }
4 │
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
+code-block.ts:2:18 lint/nursery/useExplicitType ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠ Missing return type on function.
1 │ declare module "foo" {
> 2 │ export default function bar();
│ ^^^^^^^^^^^^^^^
3 │ }
4 │
ℹ Declaring the return type makes the code self-documenting and can speed up TypeScript type checking.
ℹ Add a return type annotation.
### Valid
diff --git a/src/pages/metadata/rules.json.js b/src/pages/metadata/rules.json.js
index d82245cee..49d941b9b 100644
--- a/src/pages/metadata/rules.json.js
+++ b/src/pages/metadata/rules.json.js
@@ -1213,7 +1213,7 @@ export function GET() {
"eslintUnusedImports": "no-unused-vars"
}
],
- "docs": " Disallow unused variables.\n\n There is an exception to this rule:\n variables that starts with underscore, e.g. `let _something;`.\n\n The pattern of having an underscore as prefix of a name of variable is a very diffuse\n pattern among programmers, and Biome decided to follow it.\n\n This rule won't report unused imports.\n If you want to report unused imports,\n enable [noUnusedImports](https://biomejs.dev/linter/rules/no-unused-imports/).\n\n From `v1.9.0`, the rule won't check unused function parameters any more.\n If you want to report unused function parameters,\n enable [noUnusedFunctionParameters](https://biomejs.dev/linter/rules/no-unused-function-parameters/).\n\n ## Examples\n\n ### Invalid\n\n ```js,expect_diagnostic\n let a = 4;\n a++;\n ```\n\n ```js,expect_diagnostic\n function foo() {}\n ```\n\n ```js,expect_diagnostic\n export function foo(myVar) {\n console.log('foo');\n }\n ```\n\n ```js,expect_diagnostic\n function foo() {\n foo();\n }\n ```\n\n ```js,expect_diagnostic\n const foo = () => {\n foo();\n };\n ```\n\n ```ts,expect_diagnostic\n export function f() {}\n ```\n\n ### Valid\n\n ```js\n function foo(b) {\n console.log(b)\n };\n foo();\n ```\n\n ```js\n export function foo(_unused) {}\n ```\n\n ```ts\n function used_overloaded(): number;\n function used_overloaded(s: string): string;\n function used_overloaded(s?: string) {\n return s;\n }\n used_overloaded();\n ```\n"
+ "docs": " Disallow unused variables.\n\n There is an exception to this rule:\n variables that starts with underscore, e.g. `let _something;`.\n\n The pattern of having an underscore as prefix of a name of variable is a very diffuse\n pattern among programmers, and Biome decided to follow it.\n\n This rule won't report unused imports.\n If you want to report unused imports,\n enable [noUnusedImports](https://biomejs.dev/linter/rules/no-unused-imports/).\n\n :::caution\n From `v2.0.0`, the rule won't check unused function parameters any more.\n If you want to report unused function parameters,\n enable [noUnusedFunctionParameters](https://biomejs.dev/linter/rules/no-unused-function-parameters/).\n :::\n\n ## Examples\n\n ### Invalid\n\n ```js,expect_diagnostic\n let a = 4;\n a++;\n ```\n\n ```js,expect_diagnostic\n function foo() {}\n ```\n\n ```js,expect_diagnostic\n export function foo(myVar) {\n console.log('foo');\n }\n ```\n\n ```js,expect_diagnostic\n function foo() {\n foo();\n }\n ```\n\n ```js,expect_diagnostic\n const foo = () => {\n foo();\n };\n ```\n\n ```ts,expect_diagnostic\n export function f() {}\n ```\n\n ### Valid\n\n ```js\n function foo(b) {\n console.log(b)\n };\n foo();\n ```\n\n ```js\n export function foo(_unused) {}\n ```\n\n ```ts\n function used_overloaded(): number;\n function used_overloaded(s: string): string;\n function used_overloaded(s?: string) {\n return s;\n }\n used_overloaded();\n ```\n"
},
"useArrayLiterals": {
"deprecated": false,
@@ -1449,7 +1449,7 @@ export function GET() {
"eslintTypeScript": "no-restricted-imports"
}
],
- "docs": " Disallow specified modules when loaded by import or require.\n\n ## Examples\n \n ```json\n {\n \"noRestrictedImports\": {\n \"options\": {\n \"paths\": {\n \"lodash\": \"Using lodash is not encouraged\",\n \"underscore\": \"Using underscore is not encouraged\"\n }\n }\n }\n }\n ```\n\n **Since**: `v2`\n \n ```json,options\n {\n \"options\": {\n \"paths\": {\n \"lodash\": \"Using lodash is not encouraged.\",\n \"underscore\": \"\",\n \"import-foo\": { \"importNames\": [\"Bar\"] },\n \"import-bar\": { \"allowImportNames\": [\"Bar\"] }\n }\n }\n }\n ```\n\n ### Invalid\n\n ```js,expect_diagnostic,use_options\n import \"lodash\";\n import \"allowed-import\";\n ```\n\n ```js,expect_diagnostic,use_options\n const underscore = await import(\"underscore\");\n ```\n\n ```js,expect_diagnostic,use_options\n const lodash = require(\"lodash\");\n ```\n\n ### Valid\n\n ```js,use_options\n import \"allowed-import\";\n const myImport = await import(\"allowed-import\");\n const myImport = require(\"allowed-import\");\n ```\n\n ## Supported Import Syntaxes\n\n The rule tries to parse the context of the import to see if only one or more\n of the allowed import names have been imported from a given module.\n\n All of the following import syntaxes are supported:\n\n ### Static `import` (and re-`export`) declarations\n\n Normal static [ESM `import` declarations](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import) are supported:\n\n ```js\n // Static `import` declaration:\n // https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import\n\n import \"sideeffect-import\";\n import * as alias1 from \"namespace-import\";\n import { export1, export2 as alias2, \"string-name\" as alias3, default as defaultExport /* … */ } from \"named-import\";\n import defaultExport from \"default-import\";\n import defaultExport, * as alias5 from \"default+namespace-import\";\n import defaultExport, { export1 /* … */ } from \"default+named-import\";\n\n export * from \"namespace-import\";\n export { export1, export2 as alias2, \"string-name\" as alias3, default as defaultExport /* … */ } from \"named-import\";\n ```\n\n The TypeScript-specific [type-only imports](https://www.typescriptlang.org/docs/handbook/modules/reference.html#type-only-imports-and-exports) are also supported:\n\n ```ts\n // TypeScript-specific type-only `import` declaration:\n // https://www.typescriptlang.org/docs/handbook/modules/reference.html#type-only-imports-and-exports\n\n import { type export1, type export2 as alias2, type \"string-name\" as alias3, type default as defaultExport /* … */ } from \"named-import\";\n import type { export1, export2 as alias2, \"string-name\" as alias3, default as defaultExport /* … */ } from \"named-import\";\n import type defaultExport from \"default-import\";\n ```\n\n ### Dynamic `import()` calls\n\n Dynamic [ESM `import()` calls](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import) are also supported.\n Because the import is performed at runtime, it is not always possible to determine which import names are being used.\n Nevertheless, the rule tries to detect the following common usage patterns where the set of imported names is determined statically:\n\n ```js\n // Dynamic `import()` calls:\n // https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import\n\n import('sideeffect-import');\n await import('sideeffect-import');\n\n // ...using await + destructuring-assignment:\n const alias1 = await import('namespace-import');\n const { default: defaultExport } = await import('default-import')\n const { export1, export2: alias2, \"string-name\": alias3, default: defaultExport /* … */ } = await import(\"named-import\");\n\n // ...using then() with arrow-function + destructuring parameters:\n import('namespace-import').then(alias1 => { /* … */ });\n import('namespace-import').then((alias1) => { /* … */ });\n import('default-import').then(({ default: defaultExport }) => { /* … */ });\n import('named-import').then(({ export1, export2: alias2, \"string-name\": alias3, default: defaultExport /* … */ }) => { /* … */ });\n\n // ...using then() with function + destructuring parameters:\n import('namespace-import').then(function(alias1) { /* … */ });\n import('default-import').then(function({ default: defaultExport }) { /* … */ });\n import('named-import').then(function({ export1, export2: alias2, \"string-name\": alias3, default: defaultExport /* … */ }) { /* … */ });\n\n // Standalone `import('...')` calls that appear in some other\n // unrecognized context will be treated as a namespace import,\n // because the return value of `import('...')` is a namespace object:\n\n myFunction(...args, import(\"namespace-import\"), ...args)\n ```\n\n ### Dynamic `require()` calls\n\n NodeJS-style `require()` calls are also supported.\n Due to the way `require()` works, these are always treated as default imports.\n\n ```js\n // Dynamic `require()` call\n const defaultExport = require('default-import');\n ```\n\n ## Options\n \n ```json\n {\n \"noRestrictedImports\": {\n \"options\": {\n \"paths\": {\n \"lodash\": \"Using lodash is not encouraged\",\n \"underscore\": \"Using underscore is not encouraged\"\n }\n }\n }\n }\n ```\n \n **Since**: `v2`\n\n Use the options to specify the import paths and/or specific import names within them that you want to restrict in your source code.\n\n ```json,options\n {\n \"options\": {\n \"paths\": {\n \"lodash\": \"Using lodash is not encouraged\",\n \"underscore\": \"Using underscore is not encouraged\",\n \"import-foo\": {\n \"importNames\": [\"Bar\"],\n \"message\": \"Please use Bar from /import-bar/baz/ instead.\"\n },\n \"import-bar\": {\n \"allowImportNames\": [\"Bar\"],\n \"message\": \"Please use only Bar from import-bar.\"\n }\n }\n }\n }\n ```\n\n ### `paths`\n\n An object that lists the import paths that are either wholly or partially restricted.\n\n The keys of the object are the import paths to restrict, and the values can be:\n - A string with a custom message to show in the diagnostic when any\n - An object with additional options, as explained [below](#pathsimportimportnames).\n\n In the example below, we restrict the two paths `services-deprecated` and `constants`, with two particular messages.\n Importing `services-deprecated` will emit the message `Use services instead.`.\n Importing `constants` will emit the message `This file will be deleted soon.`:\n\n ```json,options\n {\n \"options\": {\n \"paths\": {\n \"services-deprecated\": {\n \"message\": \"Use services instead.\"\n },\n\t \"constants\": \"This file will be deleted soon.\"\n }\n }\n }\n ```\n\n ```js,expect_diagnostic,use_options\n import * as namespaceAlias from 'services-deprecated';\n ```\n\n ```js,expect_diagnostic,use_options\n import { export1 } from 'constants';\n ```\n\n ### `paths..message`\n\n Specifies the message to be shown when the restricted import is used.\n\n A default message will be generated if `message` is empty or not specified:\n\n ```json,options\n {\n \"options\": {\n \"paths\": {\n \"import-foo\": { }\n }\n }\n }\n ```\n\n ```js,expect_diagnostic,use_options\n import { export1 } 'import-foo';\n ```\n\n ### `paths..importNames`\n\n Specifies the array of import names that should be explicitly forbidden.\n The following import name specifiers are supported:\n\n - **Named import:** `\"someIdentifier\"` (`import { someIdentifier } from 'named-import'`)\n - **Default import:** `\"default\"` (`import defaultExport from 'default-import'`)\n - **Namespace import:** `\"*\"` (`import * as alias1 from 'namespace-import'`)\n - **Side effect/Bare import:** `\"\"` (`import \"sideeffect-import\"`)\n\n **Only one of `importNames` and `allowImportNames` must be specified.**\n\n ```json,options\n {\n \"options\": {\n \"paths\": {\n \"import-foo\": {\n \"importNames\": [\"Bar\"],\n \"message\": \"Please use Bar from /import-bar/baz/ instead.\"\n }\n }\n }\n }\n ```\n\n #### Invalid\n\n ```js,expect_diagnostic,use_options\n import { Bar } from 'import-foo';\n ```\n\n #### Valid\n\n ```js,use_options\n import { Foo } from 'import-foo';\n ```\n\n ### `paths..allowImportNames`\n\n Specifies the set of import names that should be explicitly allowed.\n See `importNames` for the set of supported import name specifiers.\n\n **Only one of `importNames` and `allowImportNames` must be specified.**\n\n ```json,options\n {\n \"options\": {\n \"paths\": {\n \"import-bar\": {\n \"allowImportNames\": [\"Bar\"]\n }\n }\n }\n }\n ```\n\n #### Invalid\n\n ```js,expect_diagnostic,use_options\n import { Baz } from 'import-bar';\n ```\n\n #### Valid\n\n ```js,use_options\n import { Bar } from 'import-bar';\n ```\n"
+ "docs": " Disallow specified modules when loaded by import or require.\n\n ## Examples\n\n ```json\n {\n \"noRestrictedImports\": {\n \"options\": {\n \"paths\": {\n \"lodash\": \"Using lodash is not encouraged\",\n \"underscore\": \"Using underscore is not encouraged\"\n }\n }\n }\n }\n ```\n\n **Since**: `v2`\n\n ```json,options\n {\n \"options\": {\n \"paths\": {\n \"lodash\": \"Using lodash is not encouraged.\",\n \"underscore\": \"\",\n \"import-foo\": { \"importNames\": [\"Bar\"] },\n \"import-bar\": { \"allowImportNames\": [\"Bar\"] }\n }\n }\n }\n ```\n\n ### Invalid\n\n ```js,expect_diagnostic,use_options\n import \"lodash\";\n import \"allowed-import\";\n ```\n\n ```js,expect_diagnostic,use_options\n const underscore = await import(\"underscore\");\n ```\n\n ```js,expect_diagnostic,use_options\n const lodash = require(\"lodash\");\n ```\n\n ### Valid\n\n ```js,use_options\n import \"allowed-import\";\n const myImport = await import(\"allowed-import\");\n const myImport = require(\"allowed-import\");\n ```\n\n ## Supported Import Syntaxes\n\n The rule tries to parse the context of the import to see if only one or more\n of the allowed import names have been imported from a given module.\n\n All of the following import syntaxes are supported:\n\n ### Static `import` (and re-`export`) declarations\n\n Normal static [ESM `import` declarations](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import) are supported:\n\n ```js\n // Static `import` declaration:\n // https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import\n\n import \"sideeffect-import\";\n import * as alias1 from \"namespace-import\";\n import { export1, export2 as alias2, \"string-name\" as alias3, default as defaultExport /* … */ } from \"named-import\";\n import defaultExport from \"default-import\";\n import defaultExport, * as alias5 from \"default+namespace-import\";\n import defaultExport, { export1 /* … */ } from \"default+named-import\";\n\n export * from \"namespace-import\";\n export { export1, export2 as alias2, \"string-name\" as alias3, default as defaultExport /* … */ } from \"named-import\";\n ```\n\n The TypeScript-specific [type-only imports](https://www.typescriptlang.org/docs/handbook/modules/reference.html#type-only-imports-and-exports) are also supported:\n\n ```ts\n // TypeScript-specific type-only `import` declaration:\n // https://www.typescriptlang.org/docs/handbook/modules/reference.html#type-only-imports-and-exports\n\n import { type export1, type export2 as alias2, type \"string-name\" as alias3, type default as defaultExport /* … */ } from \"named-import\";\n import type { export1, export2 as alias2, \"string-name\" as alias3, default as defaultExport /* … */ } from \"named-import\";\n import type defaultExport from \"default-import\";\n ```\n\n ### Dynamic `import()` calls\n\n Dynamic [ESM `import()` calls](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import) are also supported.\n Because the import is performed at runtime, it is not always possible to determine which import names are being used.\n Nevertheless, the rule tries to detect the following common usage patterns where the set of imported names is determined statically:\n\n ```js\n // Dynamic `import()` calls:\n // https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import\n\n import('sideeffect-import');\n await import('sideeffect-import');\n\n // ...using await + destructuring-assignment:\n const alias1 = await import('namespace-import');\n const { default: defaultExport } = await import('default-import')\n const { export1, export2: alias2, \"string-name\": alias3, default: defaultExport /* … */ } = await import(\"named-import\");\n\n // ...using then() with arrow-function + destructuring parameters:\n import('namespace-import').then(alias1 => { /* … */ });\n import('namespace-import').then((alias1) => { /* … */ });\n import('default-import').then(({ default: defaultExport }) => { /* … */ });\n import('named-import').then(({ export1, export2: alias2, \"string-name\": alias3, default: defaultExport /* … */ }) => { /* … */ });\n\n // ...using then() with function + destructuring parameters:\n import('namespace-import').then(function(alias1) { /* … */ });\n import('default-import').then(function({ default: defaultExport }) { /* … */ });\n import('named-import').then(function({ export1, export2: alias2, \"string-name\": alias3, default: defaultExport /* … */ }) { /* … */ });\n\n // Standalone `import('...')` calls that appear in some other\n // unrecognized context will be treated as a namespace import,\n // because the return value of `import('...')` is a namespace object:\n\n myFunction(...args, import(\"namespace-import\"), ...args)\n ```\n\n ### Dynamic `require()` calls\n\n NodeJS-style `require()` calls are also supported.\n Due to the way `require()` works, these are always treated as default imports.\n\n ```js\n // Dynamic `require()` call\n const defaultExport = require('default-import');\n ```\n\n ## Options\n\n ```json\n {\n \"noRestrictedImports\": {\n \"options\": {\n \"paths\": {\n \"lodash\": \"Using lodash is not encouraged\",\n \"underscore\": \"Using underscore is not encouraged\"\n }\n }\n }\n }\n ```\n\n **Since**: `v2`\n\n Use the options to specify the import paths and/or specific import names within them that you want to restrict in your source code.\n\n ```json,options\n {\n \"options\": {\n \"paths\": {\n \"lodash\": \"Using lodash is not encouraged\",\n \"underscore\": \"Using underscore is not encouraged\",\n \"import-foo\": {\n \"importNames\": [\"Bar\"],\n \"message\": \"Please use Bar from /import-bar/baz/ instead.\"\n },\n \"import-bar\": {\n \"allowImportNames\": [\"Bar\"],\n \"message\": \"Please use only Bar from import-bar.\"\n }\n }\n }\n }\n ```\n\n ### `paths`\n\n An object that lists the import paths that are either wholly or partially restricted.\n\n The keys of the object are the import paths to restrict, and the values can be:\n - A string with a custom message to show in the diagnostic when any\n - An object with additional options, as explained [below](#pathsimportimportnames).\n\n In the example below, we restrict the two paths `services-deprecated` and `constants`, with two particular messages.\n Importing `services-deprecated` will emit the message `Use services instead.`.\n Importing `constants` will emit the message `This file will be deleted soon.`:\n\n ```json,options\n {\n \"options\": {\n \"paths\": {\n \"services-deprecated\": {\n \"message\": \"Use services instead.\"\n },\n\t \"constants\": \"This file will be deleted soon.\"\n }\n }\n }\n ```\n\n ```js,expect_diagnostic,use_options\n import * as namespaceAlias from 'services-deprecated';\n ```\n\n ```js,expect_diagnostic,use_options\n import { export1 } from 'constants';\n ```\n\n ### `paths..message`\n\n Specifies the message to be shown when the restricted import is used.\n\n A default message will be generated if `message` is empty or not specified:\n\n ```json,options\n {\n \"options\": {\n \"paths\": {\n \"import-foo\": { }\n }\n }\n }\n ```\n\n ```js,expect_diagnostic,use_options\n import { export1 } 'import-foo';\n ```\n\n ### `paths..importNames`\n\n Specifies the array of import names that should be explicitly forbidden.\n The following import name specifiers are supported:\n\n - **Named import:** `\"someIdentifier\"` (`import { someIdentifier } from 'named-import'`)\n - **Default import:** `\"default\"` (`import defaultExport from 'default-import'`)\n - **Namespace import:** `\"*\"` (`import * as alias1 from 'namespace-import'`)\n - **Side effect/Bare import:** `\"\"` (`import \"sideeffect-import\"`)\n\n **Only one of `importNames` and `allowImportNames` must be specified.**\n\n ```json,options\n {\n \"options\": {\n \"paths\": {\n \"import-foo\": {\n \"importNames\": [\"Bar\"],\n \"message\": \"Please use Bar from /import-bar/baz/ instead.\"\n }\n }\n }\n }\n ```\n\n #### Invalid\n\n ```js,expect_diagnostic,use_options\n import { Bar } from 'import-foo';\n ```\n\n #### Valid\n\n ```js,use_options\n import { Foo } from 'import-foo';\n ```\n\n ### `paths..allowImportNames`\n\n Specifies the set of import names that should be explicitly allowed.\n See `importNames` for the set of supported import name specifiers.\n\n **Only one of `importNames` and `allowImportNames` must be specified.**\n\n ```json,options\n {\n \"options\": {\n \"paths\": {\n \"import-bar\": {\n \"allowImportNames\": [\"Bar\"]\n }\n }\n }\n }\n ```\n\n #### Invalid\n\n ```js,expect_diagnostic,use_options\n import { Baz } from 'import-bar';\n ```\n\n #### Valid\n\n ```js,use_options\n import { Bar } from 'import-bar';\n ```\n"
},
"noSecrets": {
"deprecated": false,