simplify the life

千万别在开发阶段用 uglify 插件了!(from Requirejs to Webpack)

webpack 各种好用,打算把 sf.gg 的前端构建工具从 gulp+requirejs 尝试着迁移到 webpack,没想到刚迈出第一步随即翻车。

因为 sf.gg 本质是个后端路由项目,每个页面一个打包的 js 文件,所以需要多个入口,即 multi-entry-points。简单地修改了三个页面,将 AMD 辛苦改成了 CommonJS 形式(虽然 webpack 也支持 AMD,但是我觉得如果要修改就要改地彻底)。然后用 webpack-dev-server 启动前端 server,三个入口,打包共用时 20s 左右,这时还不觉得不妥,然后修改了某个入口文件,保存,rebuild,同样耗时大概 20s,我看了命令行的输出,看起来像是 webpack 将所有入口都重新编译了一把。这就尴尬了,页面有一百多个,如果重新编译,那岂不是要完蛋?

难道 webpack 不会增量编译?如此不智能?带着这个疑问,我开始搜索答案,但是终究没有找到解决办法,最后抱着试试看的心情在知乎 提问,一波是我关注很久的前端大拿,他觉得是我配置错了,我当时觉得其实我没有任何配置啊,随即决定写个 demo 反驳,写着写着我惊讶地发现把原来三个入口的代码都删地只剩下一行,打包都要接近 10s,最后我终于定位到了错误,没错,就是他!uglifyjs-webpack-plugin!我在开发阶段用了 uglify 的压缩插件,看起来只要有一处修改,这个插件都会遍历 webpack 配置的所有入口!然后就悲剧了 ...

而我一直纠结的是如何使得 webpack 支持增量编译,但是其实人家本身就做了这个功能:

When the build completes, Webpack does not exit but stays active, watching the source files for changes. If Webpack detects a source file change, it rebuilds only the changed module(s).

最后的最后,切记千万别在开发阶段压缩代码了!!!

posted on 2017-12-27 14:23 韩子迟 阅读(...) 评论(...) 编辑 收藏

导航

统计信息

News