Linter

Biome 的 linter 会静态分析你的代码以查找和修复常见错误，并帮助你编写更好的现代代码。它包含支持多种语言，并提供总共 396 条规则。

¥Biome’s linter statically analyzes your code to find and fix common errors and to help you write better, modern code. It supports multiple languages and provides a total of 396 rules.

你可以通过命令行接口 (CLI) 快速试用 Biome 代码检查工具。以下命令对项目根目录下的所有文件运行代码检查器：

¥You can quickly try the Biome linter via the CLI. The following command runs the linter on all files from the root of your project:

1
npx @biomejs/biome lint

1
pnpm exec biome lint

1
bunx --bun biome lint

1
deno run -A npm:@biomejs/biome lint

1
yarn exec biome lint

或者你可以指定一个或多个文件夹，例如 ./src 和 ./public。

¥Or you can specify one or multiple folders, for example ./src and ./public

1
npx @biomejs/biome lint ./src ./public

1
pnpm exec biome lint ./src ./public

1
bunx --bun biome lint ./src ./public

1
deno run -A npm:@biomejs/biome lint ./src ./public

1
yarn exec biome lint ./src ./public

该命令接受文件和目录列表。

¥The command accepts a list of files and directories.

如果你将 glob 作为参数传递，则你的 shell 将扩展它。生物群系不支持通配符。扩展的结果取决于你的 shell。例如，某些 shell 不支持以下命令中的递归 glob ** 或交替 {}：

¥If you pass a glob as a parameter, your shell will expand it. Biome doesn’t support globs. The result of the expansion depends on your shell. For example, some shells don’t support the recursive glob ** or the alternation {} in the following command:

1
biome lint ./src/**/*.test.{js,ts}

Shell 扩展会降低性能，并且会限制可以传递给命令的文件数量。

¥Shell expansion has a performance cost and a limit on the number of files you can pass to the command.

不建议使用通配符，请使用 includes 配置。

¥The use of globs is discouraged, instead use the includes configuration.

有关所有可用选项的更多信息，请查看 CLI 参考。

¥For more information about all the available options, check the CLI reference.

规则

¥Rules

linter 被组织成规则。规则旨在强制执行或禁止代码风格、使用可能导致 bug 的内容等等。通常，除非另有说明，否则规则之间不应冲突。Biome 规则遵循命名约定：以 use* 开头的规则旨在强制执行/建议某些内容，而以 no* 开头的规则旨在禁止某些内容。当规则遇到违反其概念的情况时，它会发出诊断信息。

¥The linter is organized into rules. A rule is meant to enforce or deny a code style, the use of something that could lead to a bug, and more. Generally, a rule shouldn’t conflict with another rule, unless told otherwise. Biome rules have a naming convention: Rules that start with use* are meant to enforce/suggest something, while rules that start with no* are meant to deny something. When a rule encounters a violation of its concept, it emits a diagnostic.

例如，noDebugger 禁止在 JavaScript 代码中使用 debugger 语句，并在发现此类语句时发出诊断信息。

¥For example, the noDebugger denies the use of debugger statements in JavaScript code, and it emits a diagnostic when it finds one.

Biome 代码检查工具自带一套推荐规则，这些规则会根据语言的不同而有所差异。当你使用默认的 Biome 配置（或不配置）运行 lint 或 check 命令时，这些规则默认启用：

¥Biome linter ships with a set of recommended rules that varies based on languages, which are enabled by default when you avail of the default Biome configuration (or no-configuration) when you run the lint or check command:

1
biome lint
2
biome check

每条 lint 规则都带有一个默认的 severity，你可以通过阅读规则文档了解更多信息。

¥Each lint rule ships with a default severity which you can learn more about by reading the documentation of the rule.

这些规则分为 groups。例如，noDebugger 规则是 suspicious 组的一部分。

¥The rules are divided into groups. For example, the noDebugger rule is part of the suspicious group.

生物群系支持与语言无关的规则。这些规则适用于多种语言，例如 noUselessEscapeInString，它可以在 JavaScript 和 CSS 中报告无用的转义序列。

¥Biome supports language-agnostic rules. Those are rules that work across more than one language, such as noUselessEscapeInString, which can report useless escape sequences in both JavaScript and CSS.

与其他代码检查工具不同，Biome 不提供任何代码格式检查规则；Biome 格式化程序旨在处理所有格式化决策。

¥Unlike other linters, Biome doesn’t provide any rules that check for code formatting; the Biome formatter is intended to handle all formatting decisions.

许多规则提供了可以自动应用的代码修复。

¥Many rules provide a code fix that can be automatically applied.

Biome 会区分 安全修复 和 不安全修复，它们的工作方式略有不同：主要区别在于，安全的修复可以在保存文件时自动应用，而不安全的修复则不能。但是，用户可以覆盖哪些修复被认为是安全的。

¥Biome makes a difference between safe fixes and unsafe fixes, which work slightly differently: The main difference is that safe fixes can be automatically applied when saving a file, while unsafe fixes can’t. Users can override which fixes are considered safe however.

Biome 代码检查工具自带一组推荐规则，这些规则会自动启用，并会根据编程语言的不同而有所变化。

¥Biome linter comes with a set of recommended rules that are automatically enabled, and vary based on the language.

安全修复

¥Safe fixes

安全修复保证不会更改代码的语义。它们可以在没有明确审查的情况下应用。

¥Safe fixes are guaranteed to not change the semantic of your code. They can be applied without explicit review.

要从 CLI 应用安全修复，请使用 --write：

¥To apply safe fixes from the CLI, use --write:

1
npx @biomejs/biome lint --write ./src

1
pnpm exec biome lint --write ./src

1
bunx --bun biome lint --write ./src

1
deno run -A npm:@biomejs/biome lint --write ./src

1
yarn exec biome lint --write ./src

在兼容 LSP 的编辑器中，你可以使用代码操作 source.fixAll.biome 在保存时应用安全的修复。请参阅扩展程序的文档，了解如何应用此规则。

¥From an LSP-compatible editor, you can apply safe fixes on save with the code action source.fixAll.biome. Refer to the documentation of your extension to learn how to apply it.

不安全修复

¥Unsafe fixes

不安全的修复可能会改变程序的语义。因此，建议手动检查更改。

¥Unsafe fixes may change the semantic of your program. Therefore, it’s advised to manually review the changes.

要从 CLI 应用安全修复和不安全修复，请使用 --write --unsafe：

¥To apply both safe fixes and unsafe fixes from the CLI, use --write --unsafe:

1
npx @biomejs/biome lint --write --unsafe ./src

1
pnpm exec biome lint --write --unsafe ./src

1
bunx --bun biome lint --write --unsafe ./src

1
deno run -A npm:@biomejs/biome lint --write --unsafe ./src

1
yarn exec biome lint --write --unsafe ./src

在兼容 LSP 的编辑器中，无法在保存时应用所有不安全的修复。在保存时更改代码的语义是不理想的。然而，你可以查看单个代码修复并选择应用它。

¥From an LSP-compatible editor, it’s not possible to apply all unsafe fixes on save. It would be undesirable to change the semantics of your code on save. However, you can review the single code fix and choose to apply it.

规则支柱

¥Rule pillars

在 Biome 中，规则应该提供信息，向用户解释规则触发的原因，并告诉他们应该如何修复错误。规则应遵循以下支柱：

¥In Biome, rules should be informative and explain to the user why a rule is triggered and tell them what they should to do fix the error. A rule should follow these pillars:

向用户解释错误。通常，这是诊断的消息。

¥Explain to the user the error. Generally, this is the message of the diagnostic.
向用户解释触发错误的原因。通常，这可以通过添加注释来实现。

¥Explain to the user why the error is triggered. Generally, this is implemented with an additional note.
告诉用户他们应该做什么。通常，这是使用代码操作实现的。如果代码操作不适用，则应在注释中告诉用户他们应该做什么来修复错误。

¥Tell the user what they should do. Generally, this is implemented using a code action. If a code action is not applicable a note should tell the user what they should do to fix the error.

如果你认为规则不遵循这些支柱，请使用打开问题。

¥If you think a rule doesn’t follow these pillars, please open an issue.

配置代码检查器

¥Configure the linter

在许多情况下，你需要根据个人需求或组织/项目的需求来更改代码检查器。Biome 允许你自定义代码检查器，本节将介绍如何进行自定义。

¥In many cases, you want to change the linter based on your personal needs, or the needs or your organisation/project. Biome allows you to customise the linter, and in this section you will learn how to do it.

禁用规则

¥Disable a rule

你可以使用 off 关闭规则。

¥You can turn off a rule with off.

以下配置禁用推荐规则 noDebugger：

¥The following configuration disables the recommended rule noDebugger:

1
{
2
  "linter": {
3
    "rules": {
4
      "suspicious": {
5
        "noDebugger": "off"
6
      }
7
    }
8
  }
9
}

禁用推荐规则

¥Disable recommended rules

你可以通过简单的配置禁用推荐规则。当你只想启用一些规则时，这可能很有用。

¥You can disable the recommended rules with a simple configuration. This may be useful in cases when you only want to enable a few rules.

1
{
2
  "linter": {
3
    "rules": {
4
      "recommended": false
5
    }
6
  }
7
}

更改规则严重性

¥Change rule severity

Biome 代码检查规则默认带有其自身的严重性级别。如果你想应用默认严重性，则可以使用 "on" 配置。

¥Biome lint rules are shipped with their own default severity. If you want to apply the default severity, you can use the "on" configuration.

例如，默认情况下不建议使用 noShoutyConstants，当触发它时，它会发出一个包含信息严重性的诊断信息。

¥For example the noShoutyConstants isn’t recommended by default, and when it’s triggered it emits a diagnostic with information severity.

如果你对默认设置满意并希望使用它，配置将如下所示：

¥If you’re happy with this default and you want to use it, the configuration will look like this:

1
{
2
  "linter": {
3
    "rules": {
4
      "style": {
5
        "noShoutyConstants": "on"
6
      }
7
    }
8
  }
9
}

如果你对默认的严重性不满意，Biome 允许你使用 "error"、"warn" 和 "info" 进行更改。

¥If you aren’t happy with the default severity, Biome allows you to change it with "error", "warn" and "info".

使用 "error" 进行诊断总是会导致 CLI 以错误代码退出。当出现违反特定规则的情况时，此严重性设置可用于阻止 CI 运行。

¥Diagnostics with the "error" always cause the CLI to exit with an error code. This severity can be useful when you want to block the CI if there’s a violation that belongs to a certain rule.

警告类似于错误，但除非使用 --error-on-warnings 标志，否则它们不会导致 CLI 以错误代码退出。warn 严重性的一个可能用途是，当你希望在给定规则仍有诊断信息的情况下使 CI 通过时。

¥Warnings are similar to errors, but they don’t cause the CLI to exit with an error code, unless the --error-on-warnings flag is used. A possible use for the warn severity is when you want to make the CI pass while there are still diagnostics for a given rule.

即使传递了 --error-on-warnings，info 严重性也不会影响 CLI 的退出状态代码。

¥The info severity won’t affect the exit status code of the CLI, even when --error-on-warnings is passed.

更改分组严重性

¥Change group severity

此外，你还可以控制组级别的 lint 规则的严重性。这样，就可以控制属于同一组的所有规则的诊断严重程度。

¥Additionally, you can control the severity of lint rules at the group level. This way, it’s possible to control the diagnostic severity of all rules that belong to a group.

例如，某个项目不需要使用 a11y 规则，因为它是后端运行的代码，所以可访问性不是问题。以下示例关闭所有规则属于 a11y 组的代码：

¥For example, a project doesn’t require the use of a11y rules because it’s code that runs at the backend, so accessibility isn’t a concern. The following example turns off all rules that belong to the a11y group:

1
{
2
  "linter": {
3
    "rules": {
4
      "a11y": "off"
5
    }
6
  }
7
}

配置代码修复

¥Configure the code fix

如上所述，规则可能会生成安全或不安全的代码修复。Biome 允许将安全的修复配置为不安全，反之亦然。你还可以完全关闭代码修复功能。

¥As explained above, rules might emit code fixes that are safe or unsafe. Biome allows configuring a safe fix to be treated as unsafe and vice-versa. You can also turn the code fix off entirely.

可以使用 fix 选项配置代码修复。它可以有三个值：

¥Code fixes can be configured using the fix option. It can have one of three values:

none：该规则不会发出代码修复；

¥none: the rule won’t emit a code fix;
safe：该规则将发出安全修复；

¥safe: the rule will emit a safe fix;
unsafe：该规则将发出不安全修复；

¥unsafe: the rule will emit an unsafe fix;

1
{
2
  "linter": {
3
    "rules": {
4
      "correctness": {
5
        "noUnusedVariables": {
6
          "level": "error",
7
          "fix": "none" // no code fix suggested for noUnusedVariables
8
        }
9
      },
10
      "style": {
11
        "useConst": {
12
          "level": "warn",
13
          "fix": "unsafe" // the code fix for `useConst` is now considered unsafe
14
        },
15
        "useTemplate": {
16
          "level": "warn",
17
          "fix": "safe" // the code fix for `useTemplate` is now considered safe
18
        }
19
      }
20
    }
21
  }
22
}

跳过规则或组

¥Skip a rule or a group

命令 biome lint 接受选项 --skip，允许禁用单个规则或规则组。

¥The command biome lint accepts an option --skip that allows disabling individual rules or groups of rules.

例如，以下命令跳过属于 style 组和 suspicious/noExplicitAny 规则的所有规则：

¥For example, the following command skips all the rules that belong to the style group and the suspicious/noExplicitAny rule:

1
biome lint --skip=style --skip=suspicious/noExplicitAny

仅运行规则或组

¥Run only a rule or a group

命令 biome lint 接受选项 --only，允许运行单个规则或规则组。

¥The command biome lint accepts an option --only that allows running individual rules or groups of rules.

例如，以下命令仅运行规则 style/useNamingConvention、规则 style/noInferrableTypes 以及属于 a11y 的规则。如果在配置中禁用规则，则其严重性级别设置为推荐规则的 error，否则设置为 warn。

¥For example, the following command runs only the rule style/useNamingConvention, the rule style/noInferrableTypes and the rules that belong to a11y. If the rule is disabled in the configuration, then its severity level is set to error for a recommended rule or warn otherwise.

1
biome lint --only=style/useNamingConvention --only=style/noInferrableTypes --only=a11y

规则选项

¥Rule options

一些规则有选项。你可以通过不同地塑造规则的值来设置它们。

¥A few rules have options. You can set them by shaping the value of the rule differently.

level 将指示诊断的严重性；

¥level will indicate the severity of the diagnostic;
options 将根据规则进行更改。

¥options will change based on the rule.

1
{
2
  "linter": {
3
    "rules": {
4
      "style": {
5
        "useNamingConvention": {
6
          "level": "error",
7
          "options": {
8
            "strictCase": false
9
          }
10
        }
11
      }
12
    }
13
  }
14
}

域名

¥Domains

域名是 Biome 的一项功能，允许按技术或域名对规则进行分组。域的示例包括 "react"、"solid" 和 "test"。

¥Domains are a Biome feature that allow for grouping rules by technology, or well, domain. Examples of domains are "react", "solid", and "test".

域：

¥A domain:

拥有自己的一套推荐规则。

¥Has its own set of recommended rules.
当 Biome 检测到 package.json 文件中的某些依赖时，可以自动启用。

¥Can be automatically enabled when Biome detects certain dependencies in your package.json file.
可以定义额外的全局变量。

¥Can define additional global variables.

当 Biome 的代码检查器检测到最近的 package.json 中存在某些依赖时，它会自动启用属于该域的规则。例如，如果检测到 mocha 依赖，Biome 将启用 test 域的推荐规则。

¥Biome’s linter will automatically enable the rules that belong to a domain when it detects certain dependencies in the nearest package.json. For example, if the mocha dependency is detected, Biome will enable the recommended rules of the test domain.

但是，如果没有 package.json 或默认配置不适用，你可以通过配置启用该域：

¥However, if there’s no package.json or the default configuration doesn’t apply, you can enable the domain via configuration:

1
{
2
  "linter": {
3
    "domains": {
4
      "test": "recommended"
5
    }
6
  }
7
}

此外，你可以使用 "all" 值启用属于某个域的所有规则：

¥Additionally, you can enable all rules that belong to a domain using the "all" value:

1
{
2
  "linter": {
3
    "domains": {
4
      "test": "all"
5
    }
6
  }
7
}

与规则和组类似，你还可以将属于 "off" 值的域的规则设置为：

¥Like rules and groups, you can also turn the rules that belong to a domains with the "off" value:

1
{
2
  "linter": {
3
    "domains": {
4
      "test": "off"
5
    }
6
  }
7
}

要了解有关每个域的更多信息，请参阅合适的页面。

¥To learn more about each domain, consult the appropriate page.

抑制 lint 规则

¥Suppress lint rules

你可以参考抑制页面。

¥You can refer to the suppression page.

与编辑器集成

¥Integration with editors

与 LSP 兼容编辑器的一流集成允许你配置 Biome 的某些行为。

¥The first-class integration with LSP-compatible editors allows you to configure certain aspects of how Biome should behave.

当 Biome 检测到违规时，它会向编辑器发送诊断信息以及任意数量的代码操作，这些操作旨在解决该诊断问题。这些操作包括：

¥When a violation is detected by Biome, a diagnostic is sent to the editor alongside with an arbitrary number of code actions, that are meant to address the diagnostic. Those actions are:

可能的代码修复。仅当规则包含代码修复时，此代码修复才会显示。无论代码修复是否安全，它都会显示。

¥A possible code fix. This code fix appears only if the rule has a code fix. The code fix appears regardless if it’s safe or unsafe.
抑制诊断信息使用内联抑制。

¥Suppress the diagnostic with an inline suppression.
抑制诊断信息使用顶层抑制。

¥Suppress the diagnostic with a top-level suppression.

通常，将光标放在诊断区域内并输入特定的快捷键（不同编辑器的快捷键可能不同），就会出现一个包含可用代码操作的工具提示。

¥Usually, by positioning your cursor in the range of the diagnostic and typing a certain shortcut (it varies per editor), a tooltip will appear with the possible code actions.

默认情况下，编辑器始终显示这些操作，但你可以选择不显示它们。

¥By default, these actions are always displayed by the editor, however it’s possible to opt-out from them.

保存时应用操作

¥Apply actions on save

使用 source.fixAll.biome 代码操作指示 Biome 在保存时应用所有安全修复。

¥Use the source.fixAll.biome code action to instruct Biome to apply all safe fixes on save.

1
{
2
  "editor.codeActionsOnSave": {
3
    "source.fixAll.biome": "explicit",
4
  }
5
}

1
{
2
  "code_actions_on_format": {
3
    "source.fixAll.biome": true,
4
  }
5
}

Use the source action code source.fixAll.biome

编辑器抑制

¥Editor suppressions

使用 source.suppressRule.inline.biome 控制编辑器是否显示内联抑制代码操作：

¥Use source.suppressRule.inline.biome to control whether the editor should show the inline suppression code action:

1
{
2
  "editor.codeActionsOnSave": {
3
    "source.suppressRule.inline.biome": "never",
4
  }
5
}

1
{
2
  "code_actions_on_format": {
3
    "source.suppressRule.inline.biome": false,
4
  }
5
}

Use the source action code source.suppressRule.inline.biome

使用 source.suppressRule.topLevel.biome 控制编辑器是否显示顶层抑制代码操作：

¥Use source.suppressRule.topLevel.biome to control whether the editor should show the top-level suppression code action:

1
{
2
  "editor.codeActionsOnSave": {
3
    "source.suppressRule.topLevel.biome": "never",
4
  }
5
}

1
{
2
  "code_actions_on_format": {
3
    "source.suppressRule.topLevel.biome": false,
4
  }
5
}

Use the source action code source.suppressRule.topLevel.biome

从其他 linters 迁移

¥Migrate from other linters

许多 Biome lint 规则都受到其他 linter 的启发。如果你想从其他代码检查工具（例如 ESLint 或 typescript-eslint）迁移过来，请查看规则来源页面。如果你是从 ESLint 迁移过来的，ESLint 中有一个专门的迁移指南。

¥Many of Biome lint rules are inspired from other linters. If you want to migrate from other linters such as ESLint or typescript-eslint, check the rules sources page. If you are migrating from ESLint, there’s a dedicated migration guide.

使用命令 biome migrate eslint 将 eslint 配置文件中定义的规则移植到 biome.json：

¥Use the command biome migrate eslint to port the rules defined in your eslint configuration file to biome.json:
Terminal window
```
1
biome migrate eslint
```
使用以下命令，通过抑制 Biome 捕获到的潜在新规则来对项目进行 Lint 检查：

¥Lint the project by suppressing possible new rules that are caught by Biome, using the following command:
Terminal window
```
1
biome lint --write --unsafe --suppress="suppressed due to migration"
```
该命令会抑制 Biome 发现的所有 linting 违规，原因为 "suppressed due to migration"。现在代码检查工具应该不会再报错，并且可以在稍后阶段移除抑制注释。

¥The command will suppress all linting violation that Biome finds, using the reason "suppressed due to migration". Now the linter shouldn’t error anymore, and it’s possible to remove the suppression comments at a later stage.

代码检查组

¥Linter Groups

代码检查器将规则分为若干组。分组旨在提供规则所属的类别。这些信息对于用户选择启用/禁用规则，以及开发者创建新的代码检查规则都非常有用。

¥The linter divides rules under groups. Groups are meant to offer some sort of category which rules falls under. This information becomes useful, for users, when choosing a rule to enable/disable, or for developers when creating new lint rules.

可访问性

¥Accessibility

规则侧重于防止可访问性问题。

¥Rules focused on preventing accessibility problems.

复杂性

¥Complexity

侧重于检查可以简化的复杂代码的规则。

¥Rules that focus on inspecting complex code that could be simplified.

正确性

¥Correctness

检测肯定不正确或无用的代码的规则。

¥Rules that detect code that is guaranteed to be incorrect or useless.

Nursery

仍在开发中的新规则。初始规则需要在稳定版本中通过配置显式选择启用，因为它们可能仍然存在错误或性能问题（即使它们被标记为推荐）。它们在每日构建版本中默认启用，但由于它们不稳定，其诊断严重性可能会设置为错误或警告，具体取决于我们是否打算在规则最终稳定后推荐该规则。初始规则一旦稳定，就会被提升到其他组，或者可能被移除。属于此组的规则不受语义版本控制。

¥New rules that are still under development. Nursery rules require explicit opt-in via configuration on stable versions because they may still have bugs or performance problems (even if they are marked as recommended). They are enabled by default on nightly builds, but as they are unstable their diagnostic severity may be set to either error or warning, depending on whether we intend for the rule to be recommended or not when it eventually gets stabilized. Nursery rules get promoted to other groups once they become stable or may be removed. Rules that belong to this group are not subject to semantic version.

性能

¥Performance

规则捕捉可以编写代码以使其运行得更快或通常更高效的方法。

¥Rules catching ways your code could be written to run faster, or generally be more efficient.

安全性

¥Security

检测潜在安全漏洞的规则。

¥Rules that detect potential security flaws.

风格

¥Style

规则强制以一致且惯用的方式编写代码。默认情况下，这些规则只会生成警告，而不会生成错误。

¥Rules enforcing a consistent and idiomatic way of writing your code. By default, these rules will only generate warnings instead of errors.

可疑

¥Suspicious

检测可能不正确或无用的代码的规则。

¥Rules that detect code that is likely to be incorrect or useless.

常见问题解答 (FAQ)

¥Frequently Asked Questions (FAQ)

为什么规则 X 存在不安全的修复？在我看来，这应该是安全的。

¥Why does rule X have an unsafe fix? It seems safe to me.

Biome 团队决定将某个修复标记为不安全的原因有很多，但主要归结为以下几点：

¥There are different reasons why the Biome team decides to mark a fix unsafe, but mostly it boils down to the following:

代码检查规则及其修复仍在积极开发中。

¥The lint rule is still under heavy development, as well as the fix.
该规则的修复可能会改变程序的语义，因此必须由用户选择启用。

¥The rule fix can change the semantics of a program, so the fix must be opted in by the user.
该规则的修复可能会降低输入和/或保存时的用户体验。例如，noUnusedVariables 会在未使用的变量名后添加 _。这可能会降低程序员在输入和保存代码时的体验。你可以通过 configuration 更改此行为。

¥The rule fix can deteriorate the DX while typing and/or saving. An example is noUnusedVariables, which adds _ to the name of unused variables. This can deteriorate the DX of programmers while typing and saving. You can change this behavior via configuration.

如果代码修复不符合这三条准则，则可能是团队忘记确保规则修复的安全性。请提交 issue 或 PR！

¥If a code fix doesn’t follow these three guidelines, it’s possible that the team forgot to make the rule fix safe. Please open an issue or send a PR!

为什么 Biome linter 比 v1 版本慢这么多？

¥Why is Biome linter so slow compared to v1?

自 Biome v2 起，我们使用名为 Scanner 的工具扩展了其架构。扫描器负责抓取项目文件并创建重要信息，例如模块图和推断类型。

¥Since Biome v2, we’ve extended its architecture with a tool called Scanner. The Scanner is responsible for crawling your project files and creating important information such as the module graph and the inferred types.

某些规则（例如 noFloatingPromises、noUnresolvedImports 或 noImportCycles）需要此类信息，否则它们将无法正常工作。通常，对于属于项目域名的规则

¥Such information is needed for some rules as noFloatingPromises, noUnresolvedImports or noImportCycles, which can’t function otherwise. Generally, for rules that belong to the project domain

扫描器是可选的，仅当属于项目域名的规则启用时才会触发。

¥The Scanner is opt-in, and it’s triggered only when a rule that belongs to the project domain is enabled.

根据我们的测试，我们注意到大致如下：

¥Based on our tests, we noticed roughly these numbers:

	不使用扫描器	使用扫描器
~2000 个文件	~800 毫秒	~2 秒
~5000 个文件	~1000 毫秒	~8 秒

值得一提的是，我们也意识到这会对性能造成影响，团队承诺会改进软件这部分的性能。

¥It’s also worth mentioning that we’re aware of this impact on performance, and the team is pledged to improve the performance in this part of the software.

请参阅性能瓶颈调查指南获取有关调查和缓解性能下降的建议。

¥See the Investigate slowness guide for advice on investigating and mitigating slow-downs.

如果你发现内存或时间方面存在异常，请提交一个 issue 并附上代码仓库的链接，以便我们提供帮助。

¥If you notice some abnormal numbers in terms of memory or time, please file an issue with a link to the repository, so we can help.

为什么 Biome 占用这么多内存？

¥Why is Biome using so much memory?

如果你使用基于 Biome 的编辑器扩展，则可能会注意到其某个进程会占用大量内存。

¥If you use an editor extension that uses Biome, you might notice that one of its processes could use a lot of memory.

如果你启用了属于项目域名的某条规则，通常就会发生这种情况。

¥This usually happens if you enable one of the rules that belong to the project domain.

自 Biome v2 起，工具链现在能够使用 TypeScript 进行类型推断，并提供更强大的规则。为此，Biome 会扫描 node_modules 文件夹中的 .d.ts 个文件，包括传递依赖的文件。

¥Since Biome v2, the toolchain is now able to use TypeScript to infer types and provide more powerful rules. To achieve this, Biome scans .d.ts files inside the node_modules folder, including those of transitive dependencies.

虽然这看起来可能是一个愚蠢的错误，但这是由于语言的工作方式而有意为之。库可以从其依赖导出类型，而终端用户可能并不依赖这些类型。

¥While this might seem a silly mistake, this is intentional due to how the language works. Libraries can export types from its dependencies, which end-users might not depend on from.

例如，你可能依赖于导出类型 Validator 的库 @org/foo，但此 Validator 来自库 @other-org/validator，而 @other-org/validator 又是 @org/foo 的依赖。库 @other-org/validator 并非项目的直接依赖。

¥For example, you might depend on from a library @org/foo that exports the type Validator, however this Validator comes from the library @other-org/validator, which is a dependency of @org/foo. However, the library @other-org/validator isn’t a direct dependency of the project.

团队意识到这一限制，并将利用时间和资源努力优化基础架构。

¥The team is aware of the constraint and will work towards optimizing the infrastructure with time and resources.

Biome v2.1 中文网 - 粤ICP备13048890号

Nodejs.cn 旗下网站