前言：
前端模块化现在已经没啥好说的了，无论是requirejs，还是seajs，但是模块化分的太细，导致请求过多，所以就需要打包。
1.人工把控依赖项，自己列出来直接打包。例如：
gulp.task('cancat', function () {
return gulp.src([a,b,c,d])
//.pipe(uglify()) 混淆
.pipe(concat('seed.js'))
.pipe(gulp.dest('./src/js'));
});
问题：依赖根本无法人工把控。是不可取的。除非项目非常非常小
2.用模块化相符的打包插件，例如requirejs 使用 r.js 或者 amd-optimize 取决使用什么build工具
2.1 或者使用browserify 或者 webpack之类的省去引入 requirejs或者seajs 加上配置项文件的问题
问题： 开发过程中，与最后打包生成的文件名字，目录都有可能有差异，所以最后需要修改引入的js目录。
或者watch监听修改，直接引入打包后的。但是这么干项目足够大的时候卡的要死，改后不生效需要再空格保存N次，
一个js语法错误构建工具崩了，还得再次编译一遍。总之十分恶心。
虽然说有很多缓存的包可以用但是还是无法没有原生态修改直接看到效果来的快实在。
3.经过参考kissy(淘宝)，avalon(司徒) 的框架。无数次操蛋的试验。发现以下几点
3.1 大公司他们有自己的一套自己的东西，有无数大牛去维护，有自己的构建工具。包括司徒自己博客上写的自己竟然才知道gulp 这句话中可以看到他们都是自给自足
3.2 kissy5.0 已经规范化了，之前自己的模块化语法糖是 kissy.add('a',function(){},requires:[依赖模块]) 引用 kissy.use('a',function(S,a){ //代码}) ，现在也规范化了标准的amd规范这么做的好处是淘宝的模块可以用任意构建工具来用了。灰常不错。其次他自己也可以无缝引用无数开源好东东。我自己根据淘宝之前的语法糖模仿写了模块化发现人家改了，让我顿悟： 如果用标准amd 或者cmd 规范构建模块。模块化工具自己写一个语法糖在未build之前自行引入依赖模块，最终根据入口文件修改配置自行切换（或者最笨的办法自行替换引入的）路径那样多好。开发过程中原生态，发布过程打包混淆带压缩。
问题：自己做模块化简单，但是功能太弱。假如你用了react，jsx语法在你的模块化工具中，你根本没有解析器，直接引入解析器js又失去模块化的作用。而且自己造轮子是很苦逼的过程。你得有大量时间精力。而且功能单一。好处就是你自己用的会非常爽等你积累成你自己的一个框架的时候（N年后）。
综合： 如果不使用类似react jsx语法需要解析的可以考虑自己写个，或者就忍受不断的编译打包，因为后期修改是肯定会有的，谁都不愿意一直改来改去引入文件的路径。
如果使用了需要解析的例如 react 的jsx 的语法，就需要时时解析，推荐使用webpack，因为他吧解析器直接抽出来配置很方便，可随时更换。虽然也需要时时编译带来的困扰，但是这个带来的好处实在太多了。智能的抽出公共部分（可根据require引入的次数来自己抽离出来）例如：
//抽离公共js
var commonsPlugin = new webpack.optimize.CommonsChunkPlugin({
name: "common", //名称
minChunks: 2//require 次数大于等于2次的模块自己抽离出来
});
他几乎包含了所有用gulp使用插件才能有的常用功能，而且可以任意引入静态资源 css img 等，而且还支持用gulp来build。自己也是刚刚使用做了个例子，里面的强大之处自己可以慢慢体会
