ousiri
commented
10 years ago - 版本问题. 可以参考http://semver.org/ 的设定. 把版本号分为major.minor.patch, 对于minor和patch的升级, 可以允许自动升级, 对于major, 则需要用户和组件开发者手动升级.
- 平台处于项目中期, 但是很多小项目要转变起来的成本比较低, 这些可以先行试水.
- 是否可以先考虑修改项目架构, 改为以组件的组织方式. 当然, 这样与compass编译冲突, 可以尽早替换为node-compass.
包管理方案探讨
bower的出现本质上是npm不能解决client端的问题，那么npm首要问题是什么？
npm依赖安装不够flat(官方说法)。简单的说就是，在client端我们不可能需要两个jQuery，所以组件a和组件b都依赖jQuery，那么安装a、b后会出现两个jQuery：
更糟糕的是，jQuery如果还有两个版本……
于是bower将依赖树打平，于是bower就出现了。当然其依赖源放在github，并且可自定义依赖源，这些也是bower比npm好的地方。
但为什么bower目前是最火的呢？
足够简单。bower除了包管理没有做其他多余的事情，所以当项目在中期时，很容易将bower添加进来，配合已有的打包方案，就能很容易的组成一套完成的开发方案。
browserify
当然有，但是可以通过构建规避。
例如上面的例子，则browserify相当于在
= require('jquery')时候配置一下，则打包的时候变成= window.$。这样即使node_modules里面有两个jquery也无关紧要(反正我不用= =b)。但这样基于npm的版本管理还有意义么？
当然我们可以从browserify学到很多东西，例如：
component
以前我们的代码分割方式是横向的，即：
但这样有个问题就是，如果引用一个组件的时候就麻烦死了，如果一个组件有HTML、CSS、Javascript，则我们需要在这三个地方引用一个组件的不同部分，这对于组件的管理带来了很多困难。
所以web component提供了另一种代码分割方法，即：
component也是基于这个思想。bower在组织只有js的组件是非常成功的，但是如果一个组件如果有css、js、template、font、image时就力不从心了。
因为在bower.json没有关于这个包其他资源文件的描述。
这很重要么？很重要，因为没有这些描述，所以使用者必须非常了解一个包里哪些资源文件是他需要的，否则他可能无法使用。
举个例子，如果组件的作者升级组件的时候将目录结构变更了，那么引用的代码或者构建的代码就只能根据这个变更进行更改了。
那么component怎么解决这个问题呢？
简单的说就是，在component.json声明的依赖直接打包进构建后的build.css和build.js文件中，并将相关静态文件移到特定目录。
但有几个问题没有解决：
component的想法是好的，但是却没有解决诸多问题，所以一直难以火起来。
duo
duo从component和browserify学到了：
duo的野心很大，她想将所有包都用统一的方式进行管理，不论是browserify、bowewr、component还是别的什么包。由于bower没有像component一样声明了所有资源文件，所以无法分析其资源文件的摆放方式。于是他们改了方案，利用使用者引用来索引这些资源，这点显然是偷学了browserify的思想。这个想法不错，但是这样切换特定版本号不是很麻烦？
比如组件a，拥有a.css，和a.js，并且已在component.json声明了静态文件，然后项目引用了组件a，那时候使用了版本0.1.0，可能在其main.js有：
而main.css中有：
如是当我要升级到0.2.0的时候，难道要将这些分散的引用全改了？配置真的可以不要么？还是说只能在大部分情况下不用？
spm
2.0从3.0的转变最大的差别还是，2.0仅仅负责包管理，3.0又把构建统一进去了，可见很多时候包管理和构建还是难以分家的。
Requirement
好，现在砖头出来了，需要各位玉的参与了。