社区条件定义

¥Community Conditions Definitions

默认情况下忽略除 "import"、"require"、"node"、"node-addons" 和 "default" 条件 在 Node.js 核心中实现 以外的条件字符串。

¥Condition strings other than the "import", "require", "node", "node-addons" and "default" conditions implemented in Node.js core are ignored by default.

其他平台可能会实现其他条件，用户条件可以通过 --conditions / -C 标志 在 Node.js 中启用。

¥Other platforms may implement other conditions and user conditions can be enabled in Node.js via the --conditions / -C flag.

由于自定义的包条件需要明确定义以确保正确使用，因此下面提供了常见的已知包条件及其严格定义的列表，以协助生态系统协调。

¥Since custom package conditions require clear definitions to ensure correct usage, a list of common known package conditions and their strict definitions is provided below to assist with ecosystem coordination.

  • "types" - 类型系统可以使用它来解析给定导出的类型文件。应始终首先包括此条件。

    ¥"types" - can be used by typing systems to resolve the typing file for the given export. This condition should always be included first.

  • "browser" - 任何网络浏览器环境。

    ¥"browser" - any web browser environment.

  • "development" - 可用于定义仅开发环境入口点，例如在开发模式下运行时提供额外的调试上下文，例如更好的错误消息。必须始终与 "production" 互斥。

    ¥"development" - can be used to define a development-only environment entry point, for example to provide additional debugging context such as better error messages when running in a development mode. Must always be mutually exclusive with "production".

  • "production" - 可用于定义生产环境入口点。必须始终与 "development" 互斥。

    ¥"production" - can be used to define a production environment entry point. Must always be mutually exclusive with "development".

对于其他运行时，特定于平台的条件键定义由 运行时键 提案规范中的 WinterCG 维护。

¥For other runtimes, platform-specific condition key definitions are maintained by the WinterCG in the Runtime Keys proposal specification.

通过向 本节的 Node.js 文档 创建拉取请求，可以将新的条件定义添加到此列表中。在此处列出新条件定义的要求是：

¥New conditions definitions may be added to this list by creating a pull request to the Node.js documentation for this section. The requirements for listing a new condition definition here are that:

  • 对于所有实现者来说，定义应该是清晰明确的。

    ¥The definition should be clear and unambiguous for all implementers.

  • 为什么需要条件的用例应该清楚地证明。

    ¥The use case for why the condition is needed should be clearly justified.

  • 应该存在足够的现有实现用法。

    ¥There should exist sufficient existing implementation usage.

  • 条件名称不应与另一个条件定义或广泛使用的条件冲突。

    ¥The condition name should not conflict with another condition definition or condition in wide usage.

  • 条件定义的列表应该为生态系统提供协调效益，否则这是不可能的。例如，对于特定于公司或特定于应用的条件，情况不一定如此。

    ¥The listing of the condition definition should provide a coordination benefit to the ecosystem that wouldn't otherwise be possible. For example, this would not necessarily be the case for company-specific or application-specific conditions.

  • 该条件应该是 Node.js 用户期望它出现在 Node.js 核心文档中。"types" 条件就是一个很好的例子：它并不真正属于 运行时键 提案，但很适合 Node.js 文档。

    ¥The condition should be such that a Node.js user would expect it to be in Node.js core documentation. The "types" condition is a good example: It doesn't really belong in the Runtime Keys proposal but is a good fit here in the Node.js docs.

上述定义可能会在适当的时候移到专门的条件仓库中。

¥The above definitions may be moved to a dedicated conditions registry in due course.