-
Notifications
You must be signed in to change notification settings - Fork 324
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
uglify 压缩报错问题及 es5-imcompatible-versions #68
Comments
uglify-bug-versions => es5-imcompatible-versions ? |
@afc163 ok,es5-incompatible-versions |
- incompatible
+ imcompatible |
酷,经常能收到这样的问题。。以后可以直接贴这篇了 |
其实说到底最根本的问题是: 编译太慢! 因为大家觉得npm包应该是只读的,重新编译确实没有太大必要。 但是其实,npm包不光是为了发布,而是为了做模块化代码分离,很多业务模块单独成一个包,并没有想着要publish,而是用lerna在本地进行代码管理,类似于一个文件夹,这个阶段,基础包源码变更是很频繁的,其实比起 "首次编译时间长" 更差的体验是 "每次修改都要重新启动打包编译" 无法HRM . 另外,解决方案的问题是 ,识别是否需要转义,es5-imcompatible-versions 和extraBabelIncludes 用的是 白名单机制 ,其实,有时候源码不一定是es6的, 也有可能是*. ts ,.tsx,.less ,*.vue 我不一定要用babel啊, 碰到这种类型的扩展文件,直接让我转不就好了,反正这种文件也不会太多的。 |
node_modules 下的 |
@sorrycc 感谢回复 ……^_^ , 这个PR 只需要去掉 exclude: /node_modules/, 就可以了吧 |
更新 umi 对于 es5-imcompatible-versions 的实现。
|
更新: umi确保 umi 在 1.2.4 或以上,然后在 export default {
es5ImcompatibleVersions: true,
} roadhog确保 roadhog 在 2.4.0-beta.3 或以上,然后在 export default {
es5ImcompatibleVersions: true,
} 参考这个使用了 query-string@6 和 get-value@3 的例子,https://github.com/umijs/umi-examples/tree/master/es5-imcompatible-versions |
D:\ybx2\wx>umi -v D:\ybx2\wx>npm run build
D:\ybx2\wx\node_modules_af-webpack@0.19.0@af-webpack\lib\getUserConfig\index.js:54 D:\ybx2\wx>umi build Failed to compile. Failed to minify the bundle. Error: 1.b829935f.async.js from UglifyJs @sorrycc 该如何配置求教 |
@sorrycc
|
解决了!找到使用了es5的npm包,然后换了一个版本 |
es5-imcompatible-versions 在 umijs 2.x以上如何使用呢? |
只能说很赞了 顶一个 |
问的人比较多,录了个视频,https://www.youtube.com/watch?v=z4pWFpPiIoc |
@sorrycc I have a PR for sorrycc/roadhog#844 which implements the af-webpack support of TerserJS (documentation) |
如何找到es5的包呢?我再报错信息中看不出来 |
@sorrycc 移动端项目依赖swiper,在ios9浏览器中白屏,使用如下配置后正常 // .umirc.ts
export default {
nodeModulesTransform: {
type: 'none',
exclude: ['swiper', 'dom7'],
},
}; swiper 官网说明 如下图 |
参考这个使用了 query-string@6 和 get-value@3 的例子,https://github.com/umijs/umi-examples/tree/master/es5-imcompatible-versions |
用 |
@baobao12356 您好,我这边也遇到了这个问题,请问怎么解决的呢?我已经折腾一早上了。。。 |
缘起
由于维护 roadhog 和 umi,收到构建方面的问题反馈比较多,其中一个常见的是打包时 uglify 压缩的问题。类似下面的报错都是这个引起的,
为啥会有这个问题?
通常 webpack 在构建时,是不会让 node_modules 下的文件走 babel tranpile 的,一是会慢很多,二是 babel@6 时编译编译过的代码会不安全(据说 babel@7 下没问题了),所以业界有个潜在的约定,npm 包发布前需要先用 babel 转出一份 es5 的代码。
但是有些 npm 包不遵守这个约定,没有转成 es5 就发上去,比如 query-string@6。然后压缩工具 uglify 又只支持 es5 的语法,遇到
const
、let
、()=>
类似的语法,就抛错了。解决
有多个解决方法,但各有利弊。
使用 uglify-es 进行压缩
uglify-es 支持 es6 语法,所以不会报错。但问题是如果你需要在 IE11 及以下,或者其他的低版本浏览器里跑时,就会报错、白屏了。
让 babel 编译 node_modules 下的文件
由于 babel@7 可以保证编译编译过的代码不会出问题,这不失为一个好的解决方案,比如 create-react-app 会在下个版本考虑用这个方案,参考 facebook/create-react-app#3776。问题是会让本来就比较慢的 dev、build 流程雪上加霜。
babel-engine-plugin
跟进 npm 包的 engine 配置做按需编译。缺点是使用者比较少,如果 npm 包开发者不遵循这个规则一样会出问题。
umi/roadhog 提供的 extraBabelIncludes 配置
umi/roadhog 默认也是仅用 babel 编译项目文件,但提供了额外的 extraBabelInclude 配置可以指定 node_modules 下的文件。比如:
问题是无法提前预知,都是出错了一脸那啥,翻 issue 或者提问后才知道。而且找到哪个依赖用了 es6 语法也比较麻烦。
所以,有没有一种能提前预知(用户无感知),并且不降低 webpack 构建速度的方案?
es5-imcompatible-versions
经过讨论,我们建了一个 es5-imcompatible-versions,用于收集 uglify 压缩有问题的 npm 包版本。然后再提供配套工具,自动 resolve 到项目里有问题的 npm 包路径,添加到 babel-loader 的 include 参数里。
然后,
umi
确保 umi 在 1.2.4 或以上,然后在
.webpackrc
里配:roadhog
确保 roadhog 在 2.4.0-beta.3 或以上,然后在
.webpackrc
里配:参考这个使用了 query-string@6 和 get-value@3 的例子,https://github.com/umijs/umi-examples/tree/master/es5-imcompatible-versions
最后,这事情是否能做成,就靠大家一起共建了。
参考
The text was updated successfully, but these errors were encountered: