add a components.json file for bower

[Keith Yao]

https://github.com/twitter/bower

[Dexter Yang]

@kebot 我不推荐bower的设计和它默认提供的安装方式，component.json本身跟package.json是重复的，假如不同用户使用不同的包管理工具，是不是要求所有开源项目都必须在根目录下放一大堆名字各异内容重复的配置文件呢，像volo那样直接复用package.json是更好的设计，实际上我也不推荐volo或任何需要提供额外配置、自建生态系统、限制项目结构的依赖管理工具，而是提倡“惯例优于配置”、不是要求开源项目开发者提供配置而是为使用者提供配置选择、能够基于需求自由组织本地项目的“被动式”依赖管理（见下面的istatic）。bower的优点是“做的事情少”，所以更适合作为nodejs工具的底层依赖（处理各种代码仓库的下载和同步），也因为这个原因，“component.json”更容易成为一个主流的配置文件，但至少在当前还存在很多不确定因素，还没必要去迁就它。

你可以试试OzJS推荐的istatic：

http://ozjs.org/#toolchain
https://github.com/mockee/istatic

[Dexter Yang]

假设component.json已经是一个de facto标准，也实践证明同一个开源项目在前端和后端的使用方式差别过大，有必要各自存在一份配置文件（component.json和package.json），并且component.json是concept胜过implementation，同时被多种工具（比如istatic）实现和使用。那么还存在三个未解决的问题：

1，更小的粒度。比如DollarJS的依赖是“mo”库下面的“lang”模块，在即将发布的新版里，依赖被进一步收缩为几个子模块：

define("dollar", [
    "mo/lang/es5",
    "mo/lang/mix",
    "mo/lang/type"
], function(

component.json当前的spec和实现里都没法支持这种粒度。

我考虑在istatic里提供这种支持：

"dependencies": {
    "dexteryy/mo/lang/es5": "*"  // dexteryy是git仓库名，mo是项目名，lang/es5是路径和文件名
 },

istatic install dexteryy/mo#1.0.2:lang/es5

2, 更抽象的依赖。比如DollarJS是依赖module loader的，可以是oz.js，也可以是require.js、ender.js或其他库，同样mo/lang/es5也可以换成其他实现或在某些项目中不再必要，如果直接在component.json里写死对某个库的依赖，显然是倒退和局限。

这个问题的解决方法之一是用一种类似接口的依赖配置来解决，比如：

istatic install */es5

安装时提示用户选择具体的es5 shim实现

另一种方法是允许在本地配置中映射或替代依赖关系中的namespace，跟oz.js的远程模块用法类似。比如：

"dependencies": {
    "jrburke/requirejs": {
        "dexteryy/OzJS": ">=2.5"
    }  
 },

3, 构建步骤。很多开源项目的代码仓库里无法提供或不方便提供可被直接使用的发布文件，需要rake/make/ant/grunt的构建，在一些老项目里（比如jquery），这种设计的目的是为了让用户可以定制模块组合，而在新项目中，也会继续存在这种需求，比如假设DollarJS的源代码完全用commonjs/nodejs的方式来写，如果用户使用require.js，就需要构建成AMD风格的发布文件，如果使用某种更精简的模块实现，则需要构建成其他风格的代码。

总之就是说需要在component.json中提供构建选项或允许在本地项目中配置构建方式（我更倾向后者），比如：

"dependencies": {
    "dexteryy/DollarJS": {
        "version": "*",
        "build": ["grunt oz:transfer", "cp src/* dist/*"]
    }
 },

所以我可能会在istatic支持了以上特性之后，再给OzJS的项目添加component.json，否则并没多少实用价值。