李殿斌

这个库的语法新奇，建议一些参数的命名follow下原生sql

> @daaaabeen 能给点具体的例子吗？ 将 limit 、group by 、having 等操作放到where 里，这样设计感觉不太合理

结合 ISSUE #332 我简单整理了以下 unimport 的流程，不知道是否合理 unimport 流程： 1.从 module.conf 中找到包的信息 2.读这个包的 package.json 找到所有依赖 3.对每个依赖重复2-3过程，知道把所有依赖遍历完 4.把所有依赖合并成一个数组，合并时去重，数组中每一项是 `{packageName}` ，一个包在数组中只出现一次 5.从 moudule.conf 中找到其他包的信息，依次执行2-4，并最终合并成一个数组 6.把4中的数组除掉，在5中的部分包，构成最终要 unimport 掉的包 7.删除掉这些包并更新 module.conf [注1] edp不支持同一包的多个不同版本共存，所以 unimport 时不用考虑...

对，所以针对现在这种结构是没有办法处理要unimport的包的依赖包的，因为没有办法确定他依赖的包是否只有他自己依赖，所以需要更明确的依赖关系的描述才能做到unimport

那我按 #332 的思路做一下，不过我技术比较渣，大牛们多多指点

@errorrik edp.dependencies, efe.dependencies, dependencies这三个是什么区别，在import时是按什么规则写入的？ 现在的逻辑好像是将依赖写入到package.json的edp.dependencies,如果没有这个文件，就尝试去找.edpproj下的metadata写到metadata的dependencies里 那个efe.dependencies是什么情况下写入的呢。

那我大概整理下，主要有以下几个需要做的事~ 1. 项目的信息全部使用package.json保存，废掉.edpproj中的metadata，module.conf除了用于更新require.config信息之外，我们还能通过他来找到包的源信息 2. package.json中使用edp.dependencies（或者直接dependencies）字段来保存且只保存直接依赖的包，而所有的包应该是在module.conf中能查到的这样两者的差也就是间接依赖的包了。这样就可以获得整个的依赖树了 3. main的话，在edp下在加一个main，外层的main的路径相对与工程根目录，里面的相对于src目录，这样的话node在用的时候用外层的，edp用的时候，如果里边有就用里面的，如果没有就用外面的在加个src 4. 拉取包的整个过程，就是 @otakustay 整理的那些

@otakustay 流程整理的这个，已经做完了，unimport也加上了，已发pr，edp.main的这个，现在的edp-project里module.js好像已经对npm和edp的包入口做了处理，可以在第一层的main指定为node的入口，edp下指定main 为edp的入口就可以了