社区条件定义

【Community Conditions Definitions】

除“import”、“require”、“node”、“module-sync”、“node-addons”和“default”条件外，默认情况下会忽略Node.js 核心实现的其他条件字符串。

【Condition strings other than the "import", "require", "node", "module-sync", "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" - 可以被类型系统用于解析给定导出的类型文件。此条件应始终首先包含。
• "browser" - 任何网页浏览器环境。
• "development" - 可用于定义仅限开发的环境入口，例如在开发模式下提供额外的调试信息，如更好的错误提示。必须始终与 "production" 互斥。
• "production" - 可用于定义生产环境的入口点。必须始终与 "development" 互斥。

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

【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:】

• 定义应当清晰明确，以便所有实现者都能理解。
• 需要明确说明为什么需要该条件的使用情况。
• 应该存在足够的现有实现使用。
• 条件名称不应与其他条件定义或广泛使用的条件冲突。
• 条件定义的列表应该为生态系统提供一种协调效益，而这是在其他情况下无法实现的。例如，公司特定或应用特定的条件不一定能够实现这种效果。
• 条件应该是符合 Node.js 用户在 Node.js 核心文档中所期望的。"types" 条件是一个很好的例子：它实际上并不属于 运行时密钥 提案，但在 Node.js 文档中非常合适。

上述定义可能会在适当的时候移至专门的条件登记处。

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