工具链怎么搭建：一个前端项目的实际例子
小李刚接手公司的一个新前端项目，第一天就被要求“先把本地环境搭起来”。他打开文档，第一句就是：“请自行搭建项目所需的工具链。” 工具链这个词听起来挺高级，其实说白了，就是让代码能写、能跑、能测、能发的一整套工具组合。
比如你做饭，光有食材不行，还得有锅、灶、刀、砧板。工具链就是程序员的“厨房装备”。不同项目需要的工具链不一样，Web 前端、嵌入式开发、数据分析，各自的工具链长得完全不一样。
明确目标：你要做什么？
搭建工具链第一步不是装软件，而是搞清楚你要干什么。如果是 Vue 项目，那大概率需要 Node.js、npm 或 yarn、Vue CLI；如果是 C++ 嵌入式开发，可能就得配 GCC 编译器、Make、JTAG 调试器驱动。
小李的项目是基于 React 的，文档里写了依赖 Node.js 16+ 和 npm。他先去官网下了 Node.js 安装包，装完在命令行敲：
node -v
npm -v看到版本号出来了，说明基础环境有了。
安装构建与依赖管理工具
现代前端项目基本都用 npm 或 yarn 管理依赖。小李进到项目目录，运行：
npm install这一步会根据 package.json 自动下载所有第三方库，比如 React、Webpack、Babel。这些工具各司其职：Webpack 负责打包，Babel 把新语法转成浏览器能认的旧代码。
等依赖装完，他又执行：
npm run dev浏览器弹出了项目首页，说明本地服务起来了。但这还不够，团队还要求代码提交前自动格式化和检查语法。
集成代码质量工具
他们用的是 ESLint + Prettier。小李在项目里加了配置文件 .eslintrc.js 和 .prettierrc，然后在 package.json 里加上脚本：
"scripts": {
"lint": "eslint src/**/*.js",
"format": "prettier --write src/"
}现在每次写完代码，跑一遍 npm run lint 就能发现潜在问题，npm run format 自动统一代码风格。配合 VS Code 的插件，保存时直接自动格式化，省得被同事吐槽“代码太乱”。
自动化：让工具链自己干活
手动跑命令太麻烦，他们用 Husky 和 lint-staged 在 Git 提交时自动检查。安装后配置：
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
},
"lint-staged": {
"src/**/*.{js,jsx}": [
"npm run lint",
"npm run format"
]
}这样一来，只要有人想提交不符合规范的代码，Git 就会拦住，逼你先改好再提交。团队协作效率高了，吵架也少了。
持续集成：工具链延伸到服务器
本地搭好了，上线也不能靠手动打包上传。他们在 GitHub Actions 上配了 CI 流程：每次 push 代码，自动跑测试、检查语法、生成构建产物。
.github/workflows/ci.yml 长这样：
name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Use Node.js
uses: actions/setup-node@v3
with:
node-version: '16'
- run: npm install
- run: npm run build
- run: npm run test -- --watch=false如果测试挂了，PR 页面就会打红叉，谁也不能合并。这套流程跑顺了，上线前至少不会因为低级错误炸服。
工具链不是一次性工程，项目一变，工具也得跟着调。比如后来他们引入 TypeScript，就得加 TypeScript 编译器、更新 ESLint 插件、改 Webpack 配置。每一步都是迭代，没有“完美配置”这回事。
真正懂行的人不追求一步到位，而是让工具链能快速适应变化。就像家里厨房，一开始可能就一口锅，慢慢添上烤箱、空气炸锅、料理机，全看你要做啥饭。