如何让GitHub PR中的TypeScript编译错误更易定位？

针对100人规模TypeScript仓库、NX管理、GitHub Actions处理PR时编译错误难定位的问题，以下是几个落地性强的优化方案：

1. 精简NX日志输出，聚焦错误信息 #

NX支持通过日志级别参数过滤冗余内容，只保留错误信息：

yarn run nx affected --target=build --log-level error

如果需要保留错误前后的上下文，可结合管道命令精准截取：

yarn run nx affected --target=build 2>&1 | grep -A 15 -B 5 "Error:"

说明：2>&1将标准错误重定向到标准输出，确保错误能被grep捕获；-A 15显示错误后15行，-B 5显示错误前5行，可根据实际调整行数。

2. 自动在PR评论中推送错误详情 #

通过GitHub Actions脚本，在编译失败时自动把关键错误信息评论到PR中，开发者无需进入日志页面：

- name: 执行构建并捕获错误
  id: build_step
  run: |
    # 执行构建并保存日志
    yarn run nx affected --target=build --log-level error > build_errors.log 2>&1
    # 记录退出码
    echo "exit_code=$?" >> $GITHUB_OUTPUT
    # 提取错误内容
    if [ $? -ne 0 ]; then
      echo "error_content=$(cat build_errors.log | tr '\n' ' ')" >> $GITHUB_OUTPUT
    fi
  shell: bash

- name: 评论PR错误详情
  if: steps.build_step.outputs.exit_code != '0'
  uses: actions/github-script@v6
  with:
    script: |
      github.rest.issues.createComment({
        issue_number: context.issue.number,
        owner: context.repo.owner,
        repo: context.repo.repo,
        body: `### 编译失败关键错误\n\`\`\`bash\n${steps.build_step.outputs.error_content}\n\`\`\``
      })

3. 拆分NX构建任务，精准定位失败项目 #

使用NX的--output-style=github参数，让每个受影响项目的构建结果作为独立子步骤展示在GitHub Actions中，失败项目会直接高亮：

yarn run nx affected --target=build --output-style=github --parallel=4

这样开发者能一眼看到哪个项目编译失败，不用在大段日志中搜索。

4. 利用GitHub Actions错误标记，在Summary页高亮错误 #

通过::error::标记，将错误信息直接展示在构建页面的Summary标签页，同时在步骤列表中高亮：

- name: 构建并标记错误
  run: |
    yarn run nx affected --target=build 2>&1 | tee build_log.log
    # 捕获第一个错误行
    FIRST_ERROR=$(grep -n "Error:" build_log.log | head -n 1)
    if [ -n "$FIRST_ERROR" ]; then
      echo "::error::编译错误位置：$FIRST_ERROR"
    fi

此操作会让错误直接显示在构建页面顶部，无需展开完整日志。

补充建议 #

• 在仓库README中添加1-2步的CI失败排查指引，配合上述优化，降低团队学习成本；
• 可在nx.json中配置默认日志级别为error，避免每次命令重复添加参数：

  {
    "logging": {
      "level": "error"
    }
  }
  

内容的提问来源于stack exchange，提问作者Jonathan