千万别在开发阶段用 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).

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