修订《项目目录规范》的决议

[ecomfe]

背景

提出人

@otakustay @firede

提出原因

1. 我们现有的《项目目录规范》lib目录规定与《commonjs package spec》对lib目录的规定职责不同，commonjs规定lib用于存放Javascript文件。
2. 国外技术社区发展的很快，我们应该向成熟体系的事实标准（如：bower/components）靠拢，便于技术社会化。至少不要产生冲突导致无法融合。

   决议

请大家根据投票章节的内容，进行投票。

由于本次修订比较紧急，并且内容不多，所以投票时间截至2013-5-22（星期3）18:00。逾期视为自动放弃。

相关Spec引用

src目录用于存放开发时源文件，发布时必须（MUST）被删除。 lib目录用于存放项目引入依赖的第三方包。该目录下的内容通过平台工具管理，项目开发人员不得（MUST NOT）更改lib目录下第三方包的任何内容。

A CommonJS package will observe the following: A package.json file must be in the top level directory Binary files should be in the "bin" directory, Javascript code should be under the "lib" directory Documentation should be under the "doc" directory Unit tests should be under the "test" directory

投票

1. 修改目录名称：存放项目引入依赖的第三方包的 lib

A. 将lib修改为component B. 将lib修改为其他名字（选此选项的同学，请在后面附加建议名） C. 不修改，维持lib

2. 修改目录名称：存放开发时源文件的 src

   A. 统一更改为lib B. 业务项目使用src，package项目使用lib C. 可以使用src或lib，但不能同时存在 D. 不修改，维持src

[errorrik]

1. A
2. D

p.s. 看起来社区的component大多都是纯javascript的，我们的项目复杂度比较高。 so，个人觉得用lib作为源码目录不合适。

[leeight]

1. C
2. D

保持现状

[chriswong]

1. A
2. A

支持改变，拥抱行业标准

[otakustay]

1. B
2. A

采取标准有益于社区的推广和声誉，原lib可更改为dep或pkg，感觉component这个全称和其它目录的缩写对不上，如果只能用全称，还不如保持src和lib

[firede]

1 - B

存放依赖包的位置使用 lib 主要问题是与CJS的规范有冲突，会引起歧义。 所以命名不与其他规范(事实规范)中的命名冲突我认为都是没问题的。 至于灰大提出的 component 全称，的确不太有美感，超过8个字母的单词就隐隐觉得不顺眼。 dep 或 pkg 的缩写总觉得有些怪怪的，不支持。 之前想到了 __package__ 有点儿 python/perl 风格的命名，不过有点山寨，自己给否了。

我建议使用 vendor。 理由是易于理解，没有歧义用法。 不少项目存放引入的第三方包时会这样命名（比如PHP框架 kohana ），在Github上可以搜索到很多过滤了 vendor 目录的 .gitignore 文件： https://github.com/search?q=vendor&ref=cmdform&type=Code （还有个比较 洁癖 的原因，目录排列的时候，vendor 通常在最后，看起来比较顺眼 :joy: ）

2 - D

CJS关于源码放 lib 的规定更像是针对后端、纯JS项目设计的，并没有成为前端JS社区的事实标准（用src或者直接放在根目录的项目不在少数）。 从前端JS的特点来看，src 会更符合语义，所以我支持源码继续用 src 目录。

[firedfox]

1. B 既然跟其他规范的命名有冲突，就改了吧。 感觉component的意义不够明确，我开始想到的是3rdparty，后来看到大家提的dep和vendor也不错，都是一看就知道是依赖库。dep是缩写，跟其他的几个风格一致，遂决定投给dep。
2. B 现有的业务项目维持原状。 如果是对外开放的package项目，最好能完全符合commonjs标准，可以用lib，这样外面会更容易接受，有利于推广。

[code4fan]

1. B 支持dep，npm的package.josn用的也是dependencies
2. B 同时允许src中包含lib，做项目内的lib

[kener]

1.B：dep ps：dep其实偶尔也被联想为develop，没想到更好的，先投dep吧~ 如果不是因为“至少不要产生冲突导致无法融合”这句，真真喜欢保持lib！比其他命名都好！！

2.D 不能同意雷总再多了~

[errorrik]

调研了一些bower和component的package，发现：

frontend package，源码有放src的，有直接放在包的根目录下的，但是 没有任何frontend的package，是把源代码放在lib目录下的！！！

https://github.com/sindresorhus/screenfull.js https://github.com/medialize/URI.js https://github.com/sergi/virtual-list https://github.com/ahultgren/Reol.js https://github.com/components/polymer https://github.com/yeoman/stringify-object https://github.com/josephg/ShareJS https://github.com/learnboost/jsonp https://github.com/ForbesLindesay/ajax https://github.com/ForbesLindesay/submit

[errorrik]

看了 @otakustay 的提议，决定第一个，改投给dep。

p.s. @kener develop的缩写是dev吧...

[firede]

看到 dep 时第一印象不一定是 dependency 的惯性缩写，也可能是 deployment，deprecated 的缩写。 不过看到大家第一反应都是dependency，那说明 dep 还是比较符合直觉的，可以接受。

[firede]

@errorrik

还是有前端package将源码放 lib 的：

https://github.com/spine/spine （Update: 后来看了一下，这个是coffeescript项目，不算） https://github.com/twitter/flight https://github.com/twitter/hogan.js

放src、lib或者根目录，目前社区并没有统一的标准，完全是项目自己把握。 我仍然支持源码放 src。

[errorrik]

suger貌似也是放lib，不过确实很少，还不如src的多。最多的应该是直接放package目录下，但是这不符合我们的需求。因为社区包大多数比较小

[otakustay]

还有一点想了解的是，是否有影响力足够大的项目用src目录，这样也许cjs spec也会修改

在 2013-5-22，13:05，errorrik notifications@github.com 写道：

suger貌似也是放lib，不过确实很少，还不如src的多。最多的应该是直接放package目录下，但是这不符合我们的需求。因为社区包大多数比较小

— Reply to this email directly or view it on GitHub.

[firede]

@otakustay

影响力较大的项目，使用src的有： jquery,zepto,d3,three.js

放在根目录的有： backbone,underscore,requirejs,mustache

放在lib的有： mocha,ember.js

注：ember.js的packages目录下有若干子项目，每个子项目中源码放lib

[errorrik]

我觉得指望cjs package spec改不现实。node package的世界里，lib已经成共识了

[kitemao]

1. B

   接受dep提议

2. D

换成lib没有语义，保持原样