折腾
从 2015 到现在，短短的三年内，险些每一年折腾一下工作流的 “ 更新换代 ”。从最早最先运用 Grunt 到 Gulp 再到 Webpack，再到 Rollup，再到 Webpack@2.x ……
在这个前端东西变化如此之快的海潮里，在前端团队中，并发合作开辟多个项目，前后端星散等等情况下，设置 或许 晋级 或许 迁徙 如许的工作流 基础生产东西，每每形成消耗的就不是仅仅一个人的时刻本钱，而是十人，数十人的量级。
所以 一个靠谱、稳固、有用的工作流计划就显得迥殊重要。
Gulp
14 年 15 年终，由于构建机能等题目，已从 Grunt 迁徙到 Gulp 了 （ duowan/generator-lego ）。从开源的 Github 堆栈上不难看出，重要 工作流 是基于命令行的情势，合营 yeoman 脚手架东西，以 Gulp 使命为中心的。
关于 Gulp 定义，官方的说法是
gulp is a toolkit for automating painful or time-consuming tasks in your development workflow, so you can stop messing around and build something.
表明着，Gulp 是一个特地帮你处置惩罚一些痛楚耗时的自动化使命东西。
在这个表述中，Gulp 倾向的是于对 “使命” 这个观点的处置惩罚，而这个 “使命”，实在假如我们都尝试设置过 Gulp 的话，也就也许邃晓是怎样的一回事。
在这段时刻时期，团队面向的营业，重要分类占比最大的是 专题类，运营类。
在这类专题基础进口都是从 HTML 最先，写 HTML Dom 构造，写款式，再后能够就写一些 JS 动效或许 AJAX 。险些 JS 占比重量是超等少的，一般页以至没有剧本，纯真给到 HTML & CSS 给到后端同事直出数据。
那时刻 Gulp 所设置的使命
监听婚配文件的变化自动革新浏览器
自动编译 SASS
自动补全 CSS3 前缀
多雪碧图兼并、2x、3x 拼图
等等
基于编译 HTML / SASS / 图片的使命，已是完全满足我们的需求了。
Webpack
在 15 岁终最先，逐渐接入的营业方向转变，须要接触到 Vue，也就逐渐发明 Gulp 关于 JS 模块处置惩罚的局限性。也在这时候刻，最先权衡是不是须要迁徙到 Webpack。
关于 Webpack 定义，官方的说法是
webpack, the production / unbiased / flexible / extensible / open source module bundler.
表明着，Webpack 是一个 xxx 的打包器。
而在这个表述中，Webpack 更多的倾向于资本的整顿打包。而这个打包的最先，就是 定义在设置上的 entry。
关于 Vue 或 React 这范例的项目，Webpack 无疑是最最最适合不过了，以 JS 模块为编写进口，天生依靠链，整顿打包出 HTML / JS / CSS / 图片。
最先原本也就认为 单单工作流中心 将 Gulp 迁徙到 Webpack，如许就能够轻松处理。
直至到厥后在 雪碧图的兼并，2x / 3x 多倍图的输出上，在 Webpack 上苦苦找寻不了比较圆满的处理计划等等。
别的团队还存有一些 专题营业类 的需求，也须要兼容旧有项目，团队成员开辟时刻，切换前端生产东西的适应性等，带来了一系列的题目。
这时候迫切愿望有 越发轻便、有用的工作流计划。
Gulp + Webpack
既然 Gulp 对使命处置惩罚的壮大，而 Webpack 对 JS 模块处置惩罚的专业，也就权衡着这两者的夹杂。
由 Gulp 基于处置惩罚 HTML / SASS / 图片等部份，Webpack 重要对 JS 模块举行编译。
带着如许的主意，也有网上挺多的思绪，比方 gulp + webpack 构建多页面前端项目 。
然则都疏忽了较基础上的题目 :
每次 JS 转变都从新经由过程 Webpack 完全打包输出，效力没有保证
Webpack 下 JS 热革新应当怎样联动 Gulp 的热革新
基于处理基础痛点的，均衡功用，运用了别的一套计划 :
Webpack 基于 webpack-dev-server 启动热革新 效劳 A
browser-sync 运用 proxy 代办 效劳 A 启动 效劳 B
Gulp watch HTML / SASS / 图片 更改
Gulp watch 更改后触发 browser-sync reload
经由过程 webpack-dev-server 热革新等体式格局，优化 开辟中 JS 构建效力
经由过程 proxy 代办 让 webpack-dev-server 热革新同步革新 浏览器
Gulp 担任部份的 HTML / SASS / 图片等使命基础没有太大的更改，因此能够兼容到过往的旧项目需求，别的团队成员分外须要相识的是 JS 模块 Webpack 部份的构建，进修本钱相对下降，在 2015 岁终正式作为工作流处理计划到场在团队脚手架东西。
走多一步
2016 年终最先，因组内成员的增添，或许工作流功用版本的更新， 都伴随着保护工作流的种种题目 ( 即使写了不能再细致的文档 )，大抵回归到 Node 版本的兼容性，node_modules 的版本功用兼容，Windows / macOS 带来的兼容性等等题目。
这时候在思考着，可否有包装多一层去让这些兼容性题目都 防止开呢 ？
实在关于如许的团体封装，无疑有两条路能够走
类似于 NW 那样构建出 平台运用
类似于 PKG 那样构建出 实行顺序
在寻觅处理计划的时刻，发明了 weixin/WeFlow ，但深切发明 WeFlow 仅基于 Gulp 使命，功用远远满足不了需求。
因而便最先了轮子的重构，起首碰到题目是 node-sass 的编译依靠题目，谢谢 WeFlow 开辟者分享踩过的坑（ node-sass 依靠环境题目 · Issue ），假如团队是运用 less 或许 stylus 都无需重置那些依靠。
别的碰到了最贫苦的题目就是把 webpack 生态 迁徙到运用上去，babel 依靠 / vue-loader 依靠 / ….. 个中碰到过种种依靠被重置到全局的题目，都在 babel 或许 vue-loader 的源码上举行 切面置换依靠。
经由几个内测版本的开辟下，造出了 legoflow/legoflow
组内履行运用后也得到了 赞许的反应，经由了几个大项目标浸礼后，从功用性变得越发雄厚，兼容性上越发稳固。
而在本年 6 月也对外兼容版本 LegoFlow
走得更远
现在工作流中内置的 Webpack 照样基于 1.x 版本，实在在年终的时刻是有主意把 全部 Webpack 生态晋级为 2.x，由于在 webpack 2.x RC 时期，对 Rollup tree-shaking 已很垂涎了。
然则 Webpack 正式到 2.x，却发明没法兼容到 IE8 ( webpack2 doesn’t support IE8 · Issue #3070 · webpack/webpack )，部份营业也脱离不了 IE8 的行列。
但计划在更远一点的时刻下，看看怎样可否到完成 Webpack 1.x & 2.x 的无缝切换。
末了
前端团队频频的生产力工作流东西的迁徙，只是前端这个大海潮中最小最小的 缩影。
每次转变像是意味着 进化，在现在 这个前端急躁的年代，愿望 做着雷同事变的我们 有着自始自终的 初心 高低求索。
