Babel、ESLint、Prettier：工具链越完善，头发越少？

前端开发中，工具链的完善程度往往与开发效率成正比，但随之而来的配置复杂度也可能让人头秃。Babel、ESLint、Prettier 的组合堪称现代前端标配，它们如何协作？为何有人一边享受便利一边抱怨“发际线危机”？

Babel：JavaScript 的“时光机”

Babel 的核心任务是解决 JavaScript 的版本兼容问题。它将 ES6+ 代码转换为向后兼容的语法，确保代码能在旧浏览器中运行。

典型配置与痛点

一个基础的 .babelrc 配置可能长这样：

{
  "presets": ["@babel/preset-env"],
  "plugins": ["@babel/plugin-transform-runtime"]
}

但实际场景中，开发者常遇到以下问题：

• polyfill 混乱：@babel/polyfill 已废弃，改用 core-js 和 regenerator-runtime 后，需要显式配置 useBuiltIns 参数。
• 配置冲突：与 Webpack 或 TypeScript 共用时，可能出现重复编译或作用域问题。

// 示例：动态导入语法需要额外插件支持
import(/* webpackChunkName: "lodash" */ 'lodash').then(_ => {
  console.log(_.shuffle([1, 2, 3]));
});

ESLint：代码质量的“守门人”

ESLint 通过规则（rules）约束代码风格和质量，可自定义程度极高。

规则配置的“地狱级”选择

一个常见的 .eslintrc.js 配置：

module.exports = {
  extends: ['eslint:recommended', 'plugin:react/recommended'],
  rules: {
    'no-console': 'warn',
    'react/prop-types': 'off' // 手动关闭类型检查
  }
};

痛点包括：

• 规则优先级冲突：当继承多个预设（如 airbnb + prettier）时，规则覆盖逻辑可能令人困惑。
• 与 TypeScript 集成：需要额外安装 @typescript-eslint/parser，且需处理类型相关的规则（如 no-unused-vars）。

// TypeScript 中 ESLint 可能误报未使用的变量
interface User {
  name: string;
  age: number;
}

const printUser = ({ name }: User) => { // ESLint 可能警告 age 未使用
  console.log(name);
};

Prettier：格式化的“独裁者”

Prettier 以“零配置”著称，强制统一代码风格，但实际使用中仍需妥协。

与 ESLint 的“爱恨情仇”

通过 eslint-config-prettier 关闭 ESLint 中与 Prettier 冲突的规则后，配置可能变为：

{
  "semi": false,
  "singleQuote": true,
  "trailingComma": "es5"
}

常见问题：

• 行尾分号争议：团队是否禁用分号？Prettier 可以一键统一，但需要全员接受。
• HTML 格式化差异：JSX 中的属性换行可能因 printWidth 设置产生意外结果。

// Prettier 可能将长属性强制换行
<Component
  prop1="value1"
  prop2={veryLongVariableNameThatForcesLineBreak}
/>

工具链协作的“隐形成本”

三者结合时，需处理以下问题：

1. 执行顺序：

   • 理想流程：ESLint 检查 → Prettier 格式化 → Babel 编译。
   • 实际可能因 Husky 钩子或 IDE 插件顺序错乱。

2. 性能开销：

   • 大型项目中，babel-loader + eslint-loader 可能导致 Webpack 构建变慢。

// webpack.config.js 中的典型配置
module: {
  rules: [
    {
      test: /\.js$/,
      exclude: /node_modules/,
      use: ['babel-loader', 'eslint-loader'] // 注意顺序
    }
  ];
}

当工具链成为“负担”

过度追求工具链完善可能带来反作用：

• 配置膨胀：一个 Vue CLI 项目可能包含 10+ 个配置文件（如 .browserslistrc、.prettierignore）。
• 学习曲线：新人需要理解每层工具的职责，例如为什么既要用 ESLint 又要用 Prettier。

# 典型的配置文件列表
.babelrc
.eslintrc.js
.prettierrc
.stylelintrc
jest.config.js

头发与效率的平衡点

一些实践建议：

• 按需引入工具：小型项目可能只需 Prettier，而非全套检查。
• 统一团队配置：使用共享配置包（如 eslint-config-airbnb）减少争论。
• 自动化：通过 Git Hooks 强制校验，避免 CI 阶段才暴露问题。

// 示例：husky + lint-staged 配置
{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "*.js": ["eslint --fix", "prettier --write"]
  }
}