NX Target与原生命令的核心差异？以@nx/eslint:lint为例

1. 增量执行与智能缓存 #

Nx 的 @nx/eslint:lint executor 深度集成了 Nx 的缓存机制：

• 首次执行会缓存 lint 结果，后续仅对变更过的文件或受依赖项目变更影响的文件重新检查，大幅提升大仓项目的执行效率。
• 原生 eslint src 每次都会扫描指定路径下的所有文件，不管内容是否变更，在文件数量多的项目里重复执行耗时明显更高。

2. 单仓项目的精准范围控制 #

针对 monorepo 场景，Nx 提供了更灵活的项目级/范围级 lint 能力：

• 可以通过 nx lint <项目名> 只对指定子项目执行 lint，无需手动拼接复杂的文件路径；结合 nx affected:lint 命令，能自动识别代码变更影响的所有项目并批量执行 lint。
• 原生 eslint 需要手动指定路径（如 eslint apps/my-app/src），无法自动识别项目间的依赖关联，也没有内置的「变更影响范围」扫描能力。

3. 与 Nx 生态的深度联动 #

@nx/eslint:lint 是 Nx 统一 target 体系的一部分：

• 可以和其他 Nx target（如 build、test）配置执行依赖，比如设置「lint 不通过则阻止 build」，无需手动编写脚本串联流程。
• 能无缝对接 Nx 的任务调度、并行执行能力，比如同时 lint 多个无依赖的子项目，原生 eslint 需要借助额外工具实现类似效果。

4. 标准化的输入输出定义 #

在 project.json 中配置 @nx/eslint:lint 时，可以通过 inputs 明确指定触发 lint 的文件范围，通过 outputs 定义缓存的结果内容：

"targets": {
  "lint": {
    "executor": "@nx/eslint:lint",
    "inputs": [
      "{projectRoot}/**/*.ts",
      "{workspaceRoot}/.eslintrc.json"
    ]
  }
}

• 这种配置让 lint 触发条件清晰可控，原生 eslint 只能通过命令行参数或配置文件间接控制扫描范围，没有标准化的输入输出声明机制。

5. 统一的命令执行体验 #

所有 Nx 管理的任务（lint、test、build 等）都使用 nx 命令统一调用：

• 比如 nx lint、nx test、nx build，命令风格一致，降低团队成员的学习成本。
• 原生 eslint 是独立命令，和其他工具（如 jest、webpack）的命令风格差异大，在 monorepo 中需要维护多个不同的 package.json 脚本。

内容的提问来源于stack exchange，提问作者Joey Yi Zhao