构建工程师指南：Monorepo工具、打包器优化与CI/CD加速实战

build-engineer by 404kidwiz/claude-supercode-skills

101 周安装量

75 GitHub Stars

GitHub

安装命令

npx skills add https://github.com/404kidwiz/claude-supercode-skills --skill build-engineer

开发运维性能优化工程/构建系统

🇨🇳中文介绍

构建工程师

目的

提供构建系统和 CI/CD 优化专业知识，专注于 monorepo 工具（Turborepo、Nx、Bazel）、打包器优化（Webpack/Vite/Rspack）和增量构建。通过缓存、并行化和构建性能优化，专注于提升开发速度。

使用场景

设置 Monorepo（pnpm workspaces + Turborepo/Nx）
优化缓慢的 CI 构建（远程缓存、分片）
为提升性能从 Webpack 迁移到 Vite/Rspack
配置高级 Bazel 构建规则（Starlark）
调试复杂的依赖图或循环依赖
实现"受影响"构建（仅测试变更部分）

2. 决策框架

Monorepo 工具选择

工具	最适合	优点	缺点
Turborepo	JS/TS 生态系统	零配置，简单，Vercel 原生支持。	仅限 JS（主要），比 Bazel 粒度粗。
Nx	企业级 JS/TS	强大的插件，代码生成，图形可视化。	配置较重，有特定设计理念。
Bazel	多语言（Go/Java/JS）	密封构建，无限扩展（Google 风格）。

广告位招租

在这里展示您的产品或服务

触达数万 AI 开发者，精准高效

联系我们

工作流 1：Turborepo 设置（远程缓存）

目标： 通过重用缓存产物，将 CI 时间减少 80%。

配置 (turbo.json)

{
  "$schema": "https://turbo.build/schema.json",
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**", ".next/**"]
    },
    "test": {
      "dependsOn": ["build"],
      "inputs": ["src/**/*.tsx", "test/**/*.ts"]
    },
    "lint": {}
  }
}

远程缓存
- 链接到 Vercel 远程缓存：npx turbo link。
- 在 CI 中（GitHub Actions）：
  
  env: TURBO_TOKEN: ${{ secrets.TURBO_TOKEN }} TURBO_TEAM: ${{ secrets.TURBO_TEAM }}
执行
- turbo run build test lint
- 首次运行：5 分钟。第二次运行：100 毫秒（全速模式）。

工作流 3：Nx 受影响命令

目标： 在 monorepo 中仅运行变更项目的测试。

分析依赖图
- nx graph（可视化依赖关系：应用 A 依赖库 B）。

CI 流水线

# 仅测试受 PR 影响的项目
npx nx affected -t test --base=origin/main --head=HEAD

# 仅对受影响部分进行代码检查
npx nx affected -t lint --base=origin/main

工作流 5：面向 JS 开发者的 Bazel 概念

目标： 理解 BUILD 文件与 package.json 的对应关系。

NPM 概念	Bazel 概念
`package.json`	`WORKSPACE` / `MODULE.bazel`
`script: build`	`js_library(name = "build")`
`dependencies`	`deps = ["//libs/utils"]`
`node_modules`	`npm_link_all_packages`

代码示例 (BUILD.bazel)：

load("@aspect_rules_js//js:defs.bzl", "js_library")

js_library(
    name = "pkg",
    srcs = ["index.js"],
    deps = [
        "//:node_modules/lodash",
        "//libs/utils"
    ],
)

5. 反模式与陷阱

❌ 反模式 1：幽灵依赖

import foo from 'foo' 在本地工作，但在 CI 中失败。

'foo' 被包管理器提升，但未在 package.json 中声明。

使用 pnpm（严格模式）。它通过符号链接阻止访问未声明的依赖。

❌ 反模式 2：循环依赖

库 A 导入库 B。库 B 导入库 A。
构建失败，提示"Maximum call stack exceeded"或"Undefined symbol"。

架构中的逻辑错误。

提取共享代码： 将公共逻辑移动到库 C。
A → C, B → C。
使用 madge 工具检测循环依赖：npx madge --circular .

❌ 反模式 3：提交 `node_modules`

Git 仓库大小为 2GB。

克隆缓慢。平台特定的二进制文件会损坏。

.gitignore 必须包含 node_modules/、dist/、.turbo/、.next/。

7. 质量检查清单

缓存： 启用并验证远程缓存（命中率 > 80%）。
并行化： 尽可能并行运行任务（拓扑感知）。
大小： 生产产物经过压缩和 tree-shaking。

锁文件： pnpm-lock.yaml / package-lock.json 保持一致。
CI： 在干净的运行器上构建通过（无缓存）。
确定性： 相同的输入 = 相同的哈希值。

脚本： package.json 脚本标准化（dev、build、test、lint）。
依赖图： 依赖图是无环的（DAG）。
脚手架： 为新库/应用设置生成器。

示例 1：企业级 Monorepo 迁移

场景： 一家拥有 500 名开发人员的公司，有 4 个 React 应用和 15 个共享库，希望从独立的仓库迁移到 monorepo，以改善代码共享和 CI 效率。

工具选择：选择 Nx，因其企业级功能和图形可视化。
依赖映射：使用 madge 可视化项目间的当前依赖关系。
模块边界：定义清晰的层级（ui、utils、data-access、features）。
构建优化：配置 Nx Cloud 的远程缓存。

CI 构建时间从 45 分钟减少到 8 分钟（提升 82%）
通过共享库，代码重复率降低了 60%
受影响构建仅测试变更的项目（通常不到 1 分钟）
通过 Nx 项目推断强制执行清晰的架构边界

示例 2：Webpack 到 Rspack 迁移

场景： 一个大型电商平台由于复杂的 Webpack 配置导致生产构建缓慢（12 分钟），希望改善开发者体验。

增量迁移：从开发构建开始，生产环境暂时保留 Webpack。
配置转换：将 Webpack loader 映射到 Rspack 的等效配置。
插件兼容性：使用 rspack-plugins 来处理兼容 Webpack 的插件。
验证：运行并行构建以验证输出等价性。

指标	Webpack	Rspack	提升
开发服务器启动	45s	2s	96%
HMR 更新	8s	0.5s	94%
生产构建	12m	2m	83%
打包大小	2.4MB	2.3MB	4%

示例 3：使用分片的分布式 CI 流水线

场景： 一家游戏公司有 5000 个端到端测试，需要将 CI 时间从 90 分钟减少到 15 分钟以内，以获得快速反馈。

流水线设计：

测试分析：根据持续时间和并行化潜力对测试进行分类。
分片策略：将测试分成 20 个分片，每个运行约 250 个测试。
智能调度：使用 Nx affected 仅运行变更功能的测试。
资源优化：为并行执行配置自动扩展的运行器。

CI 流水线配置：

# GitHub Actions with Playwright sharding
- name: Run E2E Tests
  run: |
    npx playwright test --shard=${{ matrix.shard }}/${{ matrix.total }} \
      --config=playwright.config.ts
  strategy:
    matrix:
      shard: [1, 2, ..., 20]
    max-parallel: 10

端到端测试时间：90m → 12m（提升 87%）
开发者反馈循环在 15 分钟以内
通过更好的并行化，云 CI 成本降低了 30%

定义清晰的边界：从一开始就建立并强制执行项目边界。
使用严格的依赖规则：防止循环依赖并强制执行方向性。
自动化项目创建：使用生成器来确保新项目设置的一致性。
统一版本管理：使用 Changesets 或 Lerna 进行协调发布。
记录依赖关系：维护架构决策记录以追踪变更。

先分析再优化：使用 speed-measure-webpack-plugin 等工具识别瓶颈。
增量构建：配置构建工具仅重建必要部分。
并行执行：利用可用的 CPU 核心进行并行任务执行。
缓存策略：在每一层实现积极的缓存。
依赖优化：定期清理未使用的依赖（使用 bundlephobia）。

快速失败：安排测试顺序，先运行快速测试，快速捕获失败。
分片策略：智能地将测试分配到多个运行器。
缓存一切：依赖项、构建输出、测试结果。
条件执行：仅运行受变更影响的作业。
流水线即代码：将 CI 配置与代码一起进行版本控制。

工具匹配生态系统：不要强行使用不适合你技术栈的工具。
评估迁移成本：考虑总成本，而不仅仅是性能提升。
社区健康度：选择有积极维护和社区支持的工具。
插件生态系统：确保所需的集成是可用的。
团队熟悉度：考虑学习曲线和团队采用情况。

密钥扫描：绝不提交密钥；使用自动扫描。
依赖审计：定期进行漏洞扫描并自动修复。
访问控制：将 CI 凭据限制在所需的最小权限。
构建可重现性：确保可以从源代码重现构建。
审计日志：维护所有构建和部署活动的日志。

🇺🇸English

Build Engineer

Purpose

Provides build systems and CI/CD optimization expertise specializing in monorepo tooling (Turborepo, Nx, Bazel), bundler optimization (Webpack/Vite/Rspack), and incremental builds. Focuses on optimizing development velocity through caching, parallelization, and build performance.

When to Use

Setting up a Monorepo (pnpm workspaces + Turborepo/Nx)
Optimizing slow CI builds (Remote Caching, Sharding)
Migrating from Webpack to Vite/Rspack for performance
Configuring advanced Bazel build rules (Starlark)
Debugging complex dependency graphs or circular dependencies
Implementing "Affected" builds (only test what changed)

2. Decision Framework

Monorepo Tool Selection

Tool	Best For	Pros	Cons
Turborepo	JS/TS Ecosystem	Zero config, simple, Vercel native.	JS only (mostly), less granular than Bazel.
Nx	Enterprise JS/TS	Powerful plugins, code generation, graph visualization.	heavier configuration, opinionated.
Bazel	Polyglot (Go/Java/JS)	Hermetic builds, infinite scale (Google style).	Massive learning curve, complex setup.
Pnpm Workspaces	Simple Projects	Native to Node.js, fast installation.	No task orchestration (needs Turbo/Nx).

Bundler Selection

What is the priority?
│
├─ **Development Speed (HMR)**
│  ├─ Web App? → **Vite** (ESModules based, instant start)
│  └─ Legacy App? → **Rspack** (Webpack compatible, Rust speed)
│
├─ **Production Optimization**
│  ├─ Max Compression? → **Webpack** (Mature ecosystem of plugins)
│  └─ Speed? → **Rspack / Esbuild**
│
└─ **Library Authoring**
   └─ Dual Emit (CJS/ESM)? → **Rollup** (Tree-shaking standard)

Red Flags → Escalate todevops-engineer:

CI Pipeline takes > 20 minutes
node_modules size > 1GB (Phantom dependencies)
"It works on my machine" but fails in CI (Environment drift)
Secret keys found in build artifacts (Source maps)

4. Core Workflows

Workflow 1: Turborepo Setup (Remote Caching)

Goal: Reduce CI time by 80% by reusing cache artifacts.

Steps:

Configuration (turbo.json)

{
  "$schema": "https://turbo.build/schema.json",
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**", ".next/**"]
    },
    "test": {
      "dependsOn": ["build"],
      "inputs": ["src/**/*.tsx", "test/**/*.ts"]
    },
    "lint": {}
  }
}

Remote Cache

Link to Vercel Remote Cache: npx turbo link.

In CI (GitHub Actions):

env:
  TURBO_TOKEN: ${{ secrets.TURBO_TOKEN }}
  TURBO_TEAM: ${{ secrets.TURBO_TEAM }}

Execution
- turbo run build test lint
- First run: 5 mins. Second run: 100ms (FULL TURBO).

Workflow 3: Nx Affected Commands

Goal: Only run tests for changed projects in a monorepo.

Steps:

Analyze Graph
- nx graph (Visualizes dependencies: App A depends on Lib B).

CI Pipeline

# Only test projects affected by PR
npx nx affected -t test --base=origin/main --head=HEAD

# Only lint affected
npx nx affected -t lint --base=origin/main

Workflow 5: Bazel Concepts for JS Developers

Goal: Understand BUILD files vs package.json.

Mapping:

NPM Concept	Bazel Concept
`package.json`	`WORKSPACE` / `MODULE.bazel`
`script: build`	`js_library(name = "build")`
`dependencies`	`deps = ["//libs/utils"]`
`node_modules`

Code Example (BUILD.bazel):

load("@aspect_rules_js//js:defs.bzl", "js_library")

js_library(
    name = "pkg",
    srcs = ["index.js"],
    deps = [
        "//:node_modules/lodash",
        "//libs/utils"
    ],
)

5. Anti-Patterns & Gotchas

❌ Anti-Pattern 1: Phantom Dependencies

What it looks like:

import foo from 'foo' works locally but fails in CI.

Why it fails:

'foo' is hoisted by the package manager but not listed in package.json.

Correct approach:

Use pnpm (Strict mode). It prevents accessing undeclared dependencies via symlinks.

❌ Anti-Pattern 2: Circular Dependencies

What it looks like:

Lib A imports Lib B. Lib B imports Lib A.
Build fails with "Maximum call stack exceeded" or "Undefined symbol".

Why it fails:

Logic error in architecture.

Correct approach:

Extract Shared Code: Move common logic to Lib C.
A → C, B → C.
Use madge tool to detect circular deps: npx madge --circular .

❌ Anti-Pattern 3: Committing `node_modules`

What it looks like:

Git repo size is 2GB.

Why it fails:

Slow clones. Platform specific binaries break.

Correct approach:

.gitignore must include node_modules/, dist/, .turbo/, .next/.

7. Quality Checklist

Performance:

Cache: Remote caching enabled and verified (Hit rate > 80%).
Parallelism: Tasks run in parallel where possible (Topology aware).
Size: Production artifacts minified and tree-shaken.

Reliability:

Lockfile: pnpm-lock.yaml / package-lock.json is consistent.
CI: Builds pass on clean runner (no cache).
Determinism: Same inputs = Same hash.

Maintainability:

Scripts: package.json scripts standardized (dev, build, test, lint).
Graph: Dependency graph is acyclic (DAG).
Scaffolding: Generators set up for new libraries/apps.

Examples

Example 1: Enterprise Monorepo Migration

Scenario: A 500-developer company with 4 React applications and 15 shared libraries wants to migrate from separate repos to a monorepo to improve code sharing and CI efficiency.

Migration Approach:

Tool Selection : Chose Nx for enterprise features and graph visualization
Dependency Mapping : Used madge to visualize current dependencies between projects
Module Boundaries : Defined clear layers (ui, utils, data-access, features)
Build Optimization : Configured remote caching with Nx Cloud

Migration Results:

CI build time reduced from 45 minutes to 8 minutes (82% improvement)
Code duplication reduced by 60% through shared libraries
Affected builds only test changed projects (often under 1 minute)
Clear architectural boundaries enforced by Nx project inference

Example 2: Webpack to Rspack Migration

Scenario: A large e-commerce platform has slow production builds (12 minutes) due to complex Webpack configuration and wants to improve developer experience.

Migration Strategy:

Incremental Migration : Started with development builds, kept Webpack for production temporarily
Config Translation : Mapped Webpack loaders to Rspack equivalents
Plugin Compatibility : Used rspack-plugins for webpack-compatible plugins
Verification : Ran parallel builds to verify output equivalence

Performance Comparison:

Metric	Webpack	Rspack	Improvement
Dev server start	45s	2s	96%
HMR update	8s	0.5s	94%
Production build	12m	2m	83%
Bundle size	2.4MB	2.3MB	4%

Example 3: Distributed CI Pipeline with Sharding

Scenario: A gaming company with 5,000 E2E tests needs to reduce CI time from 90 minutes to under 15 minutes for fast feedback.

Pipeline Design:

Test Analysis : Categorized tests by duration and parallelism potential
Shard Strategy : Split tests into 20 shards, each running ~250 tests
Smart Scheduling : Used Nx affected to only run tests for changed features
Resource Optimization : Configured auto-scaling runners for parallel execution

CI Pipeline Configuration:

# GitHub Actions with Playwright sharding
- name: Run E2E Tests
  run: |
    npx playwright test --shard=${{ matrix.shard }}/${{ matrix.total }} \
      --config=playwright.config.ts
  strategy:
    matrix:
      shard: [1, 2, ..., 20]
    max-parallel: 10

Results:

E2E test time: 90m → 12m (87% improvement)
Developer feedback loop under 15 minutes
Reduced cloud CI costs by 30% through better parallelism

Best Practices

Monorepo Architecture

Define Clear Boundaries : Establish and enforce project boundaries from day one
Use Strict Dependency Rules : Prevent circular dependencies and enforce directionality
Automate Project Creation : Use generators for consistent new project setup
Version Packages Together : Use Changesets or Lerna for coordinated releases
Document Dependencies : Maintain architecture decision records for changes

Build Performance

Profile Before Optimizing : Use tools like speed-measure-webpack-plugin to identify bottlenecks
Incremental Builds : Configure build tools to only rebuild what's necessary
Parallel Execution : Use available CPU cores for parallel task execution
Caching Strategies : Implement aggressive caching at every layer
Dependency Optimization : Prune unused dependencies regularly (bundlephobia)

CI/CD Excellence

Fail Fast : Order tests to run fast tests first, catch failures quickly
Sharding Strategy : Distribute tests across multiple runners intelligently
Cache Everything : Dependencies, build outputs, test results
Conditional Execution : Only run jobs that are affected by the change
Pipeline as Code : Version control CI configuration alongside code

Tool Selection

Match Tool to Ecosystem : Don't force tools that don't fit your stack
Evaluate Migration Cost : Consider total cost, not just performance gains
Community Health : Choose tools with active maintenance and community support
Plugin Ecosystem : Ensure required integrations are available
Team Familiarity : Consider learning curve and team adoption

Security and Compliance

Secret Scanning : Never commit secrets; use automated scanning
Dependency Auditing : Regular vulnerability scans with automated fixes
Access Control : Limit CI credentials to minimum required permissions
Build Reproducibility : Ensure builds can be reproduced from source
Audit Logging : Maintain logs of all build and deployment activities

Weekly Installs

Repository

404kidwiz/claud…e-skills

GitHub Stars

First Seen

Jan 23, 2026

Security Audits

Gen Agent Trust HubFail SocketWarn SnykPass

Installed on

opencode58

claude-code53

codex51

gemini-cli51

cursor50

github-copilot44

Azure 升级评估与自动化工具 - 轻松迁移 Functions 计划、托管层级和 SKU

111,700 周安装

构建工程师指南：Monorepo工具、打包器优化与CI/CD加速实战

🇨🇳中文介绍

构建工程师

目的

使用场景

2. 决策框架

Monorepo 工具选择

相关 Skills

打包器选择

4. 核心工作流

工作流 1：Turborepo 设置（远程缓存）

工作流 3：Nx 受影响命令

工作流 5：面向 JS 开发者的 Bazel 概念

5. 反模式与陷阱

❌ 反模式 1：幽灵依赖

❌ 反模式 2：循环依赖

❌ 反模式 3：提交 node_modules

7. 质量检查清单

示例

示例 1：企业级 Monorepo 迁移

示例 2：Webpack 到 Rspack 迁移

示例 3：使用分片的分布式 CI 流水线

最佳实践

Monorepo 架构

构建性能

CI/CD 卓越实践

工具选择

安全与合规

🇺🇸English

Build Engineer

Purpose

When to Use

2. Decision Framework

Monorepo Tool Selection

Bundler Selection

4. Core Workflows

Workflow 1: Turborepo Setup (Remote Caching)

Workflow 3: Nx Affected Commands

Workflow 5: Bazel Concepts for JS Developers

5. Anti-Patterns & Gotchas

❌ Anti-Pattern 1: Phantom Dependencies

❌ Anti-Pattern 2: Circular Dependencies

❌ Anti-Pattern 3: Committing node_modules

7. Quality Checklist

Examples

Example 1: Enterprise Monorepo Migration

Example 2: Webpack to Rspack Migration

Example 3: Distributed CI Pipeline with Sharding

Best Practices

Monorepo Architecture

Build Performance

CI/CD Excellence

Tool Selection

Security and Compliance

最新 Skills

❌ 反模式 3：提交 `node_modules`

❌ Anti-Pattern 3: Committing `node_modules`