当 Vite/esbuild 替代 grunt-contrib-uglify 时如何保留 grunt 任务流
解读
国内一线团队正大规模从“Webpack + Grunt”或“纯 Grunt”迁移到“Vite + esbuild”。面试官想确认两点：
- 你能否在不推翻现有 Grunt 任务链的前提下，把最耗时的压缩/转译环节换成更快的 esbuild；
- 你是否理解**“任务流”≠“打包器”**，Grunt 仍负责流程编排、插件串联、环境变量注入、部署前置等，而 esbuild 只替代 uglify 的“压缩子任务”。
回答时要体现“渐进式改造”“零配置入侵”“回滚方案”三大落地关键词，否则会被认为“只会跑命令、不会保稳定”。
知识点
- grunt-contrib-uglify 的输入输出契约：src → dest，支持 sourceMap、banner、ie8 兼容开关。
- esbuild 的 CLI 与 Node API：--minify、--target、--sourcemap、--format=iife；Node API 返回 { code, map }，可同步写盘。
- grunt.task.registerMultiTask：自定义任务可读取 this.files，保持与 uglify 相同的文件对象约定，实现“透明替换”。
- grunt-contrib-watch 的 livereload 机制：只要 dest 文件被覆写，就会触发浏览器刷新，与谁生成无关。
- 国内合规要求：esbuild 默认不降级 ES5，若需兼容旧安卓（微信 X5 内核），必须显式设置 target=es2015 或更低，并引入 core-js 按需垫片。
- CI 缓存策略：esbuild 二进制可在 Jenkins/GitLab Runner 中缓存到 ~/.esbuild/bin，减少重复下载。
- 回滚开关：通过 grunt.option('legacy') 动态切换 uglify/esbuild，上线首日可一键回退。
答案
-
安装依赖
npm i -D esbuild grunt-esbuild-next（或自研轻量封装）
保留 grunt-contrib-uglify 作为回滚包，但不注册任务。 -
新建 grunt-esbuild-task.js，注册 multiTask：
- 读取 this.files，与 uglify 保持相同结构；
- 调用 esbuild.buildSync({ entryPoints: [src], minify: true, target: 'es2015', sourcemap: true, outfile: dest })；
- 若 sourceMap 为 true，追加 //# sourceMappingURL=xxx 注释；
- 统计压缩比、耗时，通过 grunt.log.writeln 输出，方便 CI 采集。
-
在 Gruntfile 中把原来 uglify 的任务名映射到新任务：
grunt.registerTask('jsmin', ['esbuild:dist'])；
其余任务流（clean、copy、rev、usemin、qunit、ssh_deploy）保持不变。 -
灰度开关
if (grunt.option('legacy')) {
grunt.loadNpmTasks('grunt-contrib-uglify');
grunt.registerTask('jsmin', ['uglify:dist']);
} -
验证
- 本地 npm run build 后，dist 目录资源 hash 与旧版一致；
- 通过 source-map-explorer 验证映射文件可正常解析；
- 在 50M 老旧代码库上，CI 构建时间从 180s 降至 45s，符合国内“分钟级交付”基线。
-
上线流程
第一天使用 esbuild，保留 uglify 镜像；第二天无回滚则移除 uglify 依赖，完成无痛切换。
拓展思考
- 双引擎压缩：对第三方库继续使用 uglify（兼容 IE），对业务代码使用 esbuild，通过文件 glob 区分，实现“差异化构建”。
- 插件下沉：把 esbuild 封装成公司内部 grunt-scaffold-esbuild，内置 target、banner、license 提取、Sentry 源码映射上传，形成标准化“一键替换”方案。
- 结合 Vite：若未来整站迁移到 Vite，可把 Grunt 仅当作“部署流水线”，通过 vite build --watch 生成资源，再由 Grunt 做 md5、cdn 上传、钉钉通知，实现“Vite 负责打包，Grunt 负责交付”的混合模式，兼顾性能与流程遗产。