Babel仅做语法转换,不校验正确性;ESLint和运行时检查才负责捕获未定义变量、API兼容性、插件配置错误等问题,CI中必须在Babel后插入这三类校验并阻断失败流程。

Babel 本身不负责校验产物正确性,它只做语法转换;真正需要在校验环节介入的是 ESLint 和运行时/构建后检查工具。CI 中不能只信任 Babel 编译成功就认为输出安全——编译通过 ≠ 代码可执行、兼容、无逻辑隐患。
为什么 Babel 的成功编译不能代表产物正确
Babel 是转译器,不是验证器。它只确保输入 JS 能被解析成 AST 并按规则生成目标代码,但不管:
- 是否引入了未声明的全局变量(如 window.foo 在严格模式下报错)
- 是否用了目标环境不支持的 API(如 Array.prototype.flatMap 未被 polyfill 覆盖)
- 是否因插件配置错误导致关键语法未转换(如漏配 @babel/plugin-transform-classes,导致 class 保留原样)
- 是否因 targets 配置过宽(如写成 {"chrome": "100"}),本地开发能跑,CI 构建机 Node 版本低却静默失败
CI 中真正该做的三类校验动作
必须在 Babel 执行之后、部署之前插入以下检查,且全部失败需阻断流水线:
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- ESLint 检查编译后代码:用 eslint --ext .js,.mjs dist/ 扫描产出目录(非 src)。启用 no-undef、no-restricted-globals 等规则,捕获未定义引用;配合 eslint-plugin-node 校验 Node 兼容性
- 运行时最小化执行验证:用 node --check dist/index.js 或 node -c dist/bundle.js 做语法预检(不执行,仅解析);对入口文件做轻量 require(如 node -e "require('./dist/index.js')")确认模块可加载
- 产物结构与内容断言:写简单脚本检查 dist/ 下是否存在预期文件、是否含 use strict、是否不含 console.log / debugger(用 grep -r 或 jq 配合 cat dist/*.js | grep -q "console\.log")
避免常见陷阱的实操要点
很多团队把 ESLint 放在 src 上 lint 就以为万事大吉,这是错的:
立即学习“Java免费学习笔记(深入)”;
- ESLint 规则必须和 Babel 输出对齐:比如开了 @babel/preset-env + core-js,ESLint 就不该报 Promise 不支持;否则 CI 会因规则冲突反复失败
- 不要跳过 .mjs 或 type: "module" 文件——Babel 默认不处理它们,需显式配置 extensions: [".js", ".mjs"]
- 若使用 Vite 或 SWC 替代 Babel,校验逻辑不变,只是检查对象从 dist/ 变为 .vite/deps/ 或 build/,路径要同步更新

















