社区条件定义

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

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

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

  • "types" - 类型系统可以使用它来解析给定导出的类型文件。 此条件应始终首先包含在内。
  • "deno" - 表示 Deno 平台的变体。
  • "browser" - 任何网络浏览器环境。
  • "development" - 可用于定义仅开发环境入口点，例如提供额外的调试上下文（例如在开发模式下运行时更好的错误消息）。 必须始终与 "production" 互斥。
  • "production" - 可用于定义生产环境入口点。 必须始终与 "development" 互斥。

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

  • 对于所有实现者来说，定义应该是清晰明确的。
  • 为什么需要条件的用例应该清楚地证明。
  • 应该存在足够的现有实现用法。
  • 条件名称不应与另一个条件定义或广泛使用的条件冲突。
  • 条件定义的列表应该为生态系统提供协调效益，否则这是不可能的。 例如，对于特定于公司或特定于应用程序的条件，情况不一定如此。

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

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

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" - can be used by typing systems to resolve the typing file for the given export. This condition should always be included first.
  • "deno" - indicates a variation for the Deno platform.
  • "browser" - any web browser environment.
  • "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" - can be used to define a production environment entry point. Must always be mutually exclusive with "development".

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.

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