lego
lego copied to clipboard
imweb
关于内部组建管理机制的讨论
目前的实现方式主要有两种：
第一种是基于duo.js和component的模式，即不提供类npmjs.org聚合和查询窗口的方式，直接和github做开源的打通；对外开源的内容直接采用github的方式管理，对内的采用gitlab的方式；在内部通过config的方式做逻辑的切换。特点：
- 更好的开源社区讨论 ：利用开源社区的issue，milestone等管理
- 缺少归类的聚合：和github应用混杂，无法快速筛选和遍历
第二种方式是基于spm的方式，通过spmjs.io + spm tools + arale 三个工具的组合建立整合的体系。内部组建提交到内部源，外部代码提交到spm的公共源。 公共源通过github建立版本和讨论体系。
- 更灵活的管理体系 ：对spmjs.io可以做聚合，甚至是吧arale的东西整合到spmjs.io的私有源上。
- 工具的改造 ：对目前有的工具和包管理做适配
1、duo.js的继承了browserify的思路，在component的基础上去掉了component.json/package.json的一些依赖配置文件，开发的时候不需要另外在关注依赖组件（css也是一样）。但是duo.js只是解决了包的使用，没有解决包的维护和开发。包的维护和开发需要里另外基于github/gitlab来管理和维护，对于前端体系来讲。一个方式是可以基于duo再包装一下解决包的开发/维护（文档） 2、spm是一个完整的体系，但是正是由于他是一些列解决方案，再具体的项目中使用的时候会有一定的工具改造维护成本（诸如spm更新等，当然spm3 已经把构建和包的发布分开，发布不依赖于构建，这一点已经很大的进步），对于未来组件的组织形式，基于这个方案可以这样。基于duo.js的思路，吸收spm的文档组织形式（包管理）我们做一层处理，打包/包的依赖单独处理，再有中间层和本身的spm衔接，至于后续spm方案改了或者换成其他的包管理工具，我们只需要处理中间层。
其实一直都觉得npm的包管理缺少一定的筛选性， 根据一个关键词检索的组件没有认证，没有说明；对生产系统的应用都是很不利的。 同时，类似的组件体系应该都要支持 内部源 这个能力。毕竟组件不是所有的内容都适合放出来。
@miniflycn 很好的思考，加入 @ousiri
版本管理上采用标准的规范 Semantic Versioning 2.0.0 即可。
今天 @herbertliu 提出 https://github.com/cortexjs/cortex 大众点评的解决方案很靠谱。 对构建和包管理采用对接的方式，也采用了SV的方案。
@ousiri 看下这里 http://cnblog.ctx.io/ ，包管理对semantic versioning的应用已经解释的很清楚了，和我们想的平级的思路是一样的。 按照这个来即可。
看了下，semantic versioning的主要思想是语义话的版本号来维护，能够通过版本号找到唯一的版本/api。兼容性也有可以从版本号明确的看出，那么这里我们可以在包管理/加载上做强制升级。
简单review了下cortex的情况：
- cortex体系是完全基于npm体系做二次开发的，npm server及npm tools
- cortex server部分的搭建依赖对npm结构的拷贝，可能存在的风险是npm结构发生较大变化后，merge代码较复杂，同时搭建比spm复杂很多。
- cortex tools本身还比较简单的进行脚手架初始化和build， 目前不支持直接提交package
今天完成以下几个事情：
- 上传spm公共源组件： 5mins
- 安装spm私有源: 5mins
- 上传spm私有源组件： 5mins
- 理解设置spm私有源配置：5mins
- 理解spm代码结构：10mins
- 安装cortex www及server： 10mins
- 安装cortex db：10mins
- sync cortex db：=。=！ 还没完成
cortex安装CouchDB太TM变态了，还没跑通，明天继续试一下。刚跑了一下spm的整体流程。确实很快。相比较而言，服务部署不是我们的强项，js改造是我们的优势，基于spm改造更适合我们。
@herbertliu
快速搞起以下几件事情：
1、 spm.io侧的代码逻辑图和分工
2、 spm工具侧的代码逻辑和分工
3、 我们的升级计划及日期表
4、 逻辑组件和UI组件的接入规范
可以提交，这个应该是之前的文档没有更新。http://ctx.io/package/edu-mobile 这个是我之前提交到cortex的测试包。
@miniflycn 怎么突然有想起这事儿。 现在lego的readme里第一行就写了大大的，fork来自spm.
本身对于组件平台，我们要做的就是先私有化，再公开化。 这是必然经历的过程。
@miniflycn 嗯，这个我们从一开始就木有回避过使用spm or duo.js的问题。。 @herbertliu 我看readme被冲掉了？ lego和lego站点都还是要加上的。
建议贡献吧，不用每个库都 fork 一份 lego-xxx，如果真有改动话则另说，spm 是 semver 的，所以发布 feature 什么的不会影响现有的。
看到你们的依赖用的是 *，尽量避免
@popomore 建议收到， @herbertliu 看一下啦，主要接口层面的几个改下就好了， 用到的子库可以和spm保持一致， * 的问题， 用install --save啦，表手动改了额。
@popomore 恩 恩，目前正在修改中，fork一份是考虑修改方便，以免需要的时候不方便改，后续如果有必要会贡献到以前的地方。* 目前正在修改，稳定之后会改掉这里哈。不用--save的原因是有其他同事在修改的时候，也不用--save来使用，和后续正式发布之后使用方式一致，也免去经常提交修改的package，等稳定版本了，再改回来。
不遵照 semver 会很不稳定，工具都达不到这要求就别想再制约开发者了。 On 2015年2月16日 周一 at 下午10:58 河伯 [email protected] wrote:
家里终于连上网了。欢迎大家继续讨论建议啊。
— Reply to this email directly or view it on GitHub https://github.com/imweb/lego/issues/1#issuecomment-74520319.