ESLint负责静态检查，Babel负责语法转译，二者无内置执行依赖；可通过npm script串联、CI/CD分步校验或husky+lint-staged左移拦截实现“先检查后转译”的质量门禁。
ESLint 和 Babel 在前端工程中各司其职：ESLint 负责静态检查（语法、风格、潜在错误），Babel 负责语法转译（如 ES2022 → ES5）。它们本身没有执行依赖关系，**不存在“ESLint 检查通过后才允许 Babel 执行”的内置机制**——但你可以通过构建流程编排实现这一效果。
用 npm script 串联检查与转译
这是最常用、最轻量的方式。将 ESLint 校验作为 Babel 转译的前置步骤，失败则中断后续流程：
- 在 package.json 中定义脚本：
"lint": "eslint src --ext .js,.jsx,.ts,.tsx",
"build": "npm run lint && babel src --out-dir lib"
}
运行 npm run build 时，若 ESLint 报错（退出码非 0），&& 会阻止 babel 命令执行。
在 CI/CD 流程中强制校验
本地开发可能跳过 lint，但上线前必须拦截。在 GitHub Actions、GitLab CI 等环境中明确分步：
立即学习“Java免费学习笔记（深入）”；
- 先运行
eslint --max-warnings 0（--max-warnings 0表示警告也视为失败） - 仅当上一步成功，再执行
babel或打包命令（如rollup/webpack） - 避免把 Babel 配置写成 “自动修复并忽略错误”，这会绕过质量门禁
借助 husky + lint-staged 提前拦截提交
把检查左移到代码提交环节，比发布时拦截更早、成本更低：
- 安装
husky和lint-staged - 配置
.husky/pre-commit脚本，调用lint-staged - 在
lint-staged中指定："*.js": ["eslint --fix", "git add"] - 这样每次
git commit都会先跑 ESLint；修复失败或仍有错误，提交被拒绝
注意 Babel 解析器与 ESLint 的配置协同
若你用 @babel/eslint-parser，需确保它不干扰规则生效（常见坑）：
- 移除
parserOptions.sourceType: "module"—— Babel 解析器会自动推断，手动指定反而导致规则失效 - 保留
ecmaVersion: "latest"和requireConfigFile: false - 确保
extends中包含语义化规则集（如plugin:react/recommended），而不仅是eslint:recommended
