usemin-cli压缩Bootstrap5 bootstrap.min.js时uglify-js报错

• 核心冲突来自工具链的语法兼容断层：usemin-cli 0.6.0 处理JS构建块时默认调用uglify-js作为压缩解析器，而3.x版本的uglify-js本身对ES6+语法的支持存在大量缺陷，仅能稳定解析ES5及更早版本的JS代码；Bootstrap 5从首个正式版开始就放弃了ES5兼容，发行的bootstrap.min.js是基于ES2020+标准语法压缩的产物，代码中包含数组解构、可选链、空值合并等现代JS语法特性，解析器遇到这些不识别的语法标记时，就会抛出JS_Parse_Error类型的SyntaxError，提示意外的标点符号[，报错定位刚好对应bootstrap.min.js中使用ES6+数组语法的位置。
• 额外诱因：bootstrap.min.js本身已经是经过压缩优化的生产环境产物，二次压缩本身不会带来明显的体积优化收益，反而会大幅提升解析出错的概率。

按优先级从高到低可选以下方案：

• 方案一：替换JS压缩引擎为terser
  1. 卸载现有不支持ES6+的uglify-js依赖，执行命令：npm uninstall uglify-js --save-dev
  2. 安装terser依赖作为替代，执行命令：npm install terser --save-dev
  3. 修改项目中usemin的压缩配置，将JS压缩处理器从uglify-js切换为terser即可。terser是uglify-js的社区维护迭代版本，原生全支持ES6+及更新的JS语法，可无报错解析Bootstrap 5的代码，压缩效率和兼容性均优于老旧的uglify-js。
• 方案二：跳过第三方压缩文件的二次处理
  调整contactus.html中的usemin构建块配置，将node_modules/bootstrap/dist/js/bootstrap.min.js标记为无需压缩的静态资源，构建时直接拷贝到输出目录再和其他自有JS合并，仅对自己编写的未压缩JS文件走uglify-js压缩流程，从根源上避免解析第三方压缩产物的报错。
• 方案三：引入ES5转译环节（不推荐）
  如果必须保留uglify-js作为压缩工具，需要在usemin构建流程前增加babel转译步骤，先把Bootstrap 5的ES6+代码转译为ES5语法，再交给uglify-js处理。该方案会大幅增加构建耗时，且需要手动维护转译规则，维护成本极高。

注意：对第三方已经压缩过的生产环境JS做二次压缩，除了解析报错风险外，极端情况下还可能破坏原有代码的执行逻辑，无特殊需求不建议做二次压缩处理。

内容的提问来源于stack exchange，提问作者Ginura Ransika