组件名统一为 index.js/html/css/less 的疑问

[nuysoft]

组件名统一为 index.js/html/css/less，例如 dropdown，方便了 Brix 拼接组件路径和加载，对于组件开发者却不够友好，会有为什么要这么强制约定的疑问。这个疑问应该是可以避免的。

参考了下 SPM 源服务器 的目录结构，组件根目录 gallery 下有文件 info.json，用于描述所有组件的信息，包括目录、名称、版本（路径）、稳定版本等，每个组件下同样有一个文件 info.json，用于描述当前组件的信息，组件的名称和结构则保持不变。

每个组件事实上需要有自己 独立的版本号，并且，基于描述组件信息的文件 info.json 可以生成一份 推荐的组件配置。

[keyapril]

这个约定源于KISSY包加载的约定，我不知道承玉当时的考虑基于什么，这个需要@承玉。
那Brix为什么会延续这样的命名，甚至你觉得有点泛滥，我想说，这是有好处。
我们不再需要你说的那个info.json，我们只需要基于目录就能完成对组件的管理，不是有句话叫约定大于配置嘛。

[cyjake]

组件确实应该有独立的版本号，接下来会把 gallery 移出，放到 bpm 里管理起来。

组件代码约定为 index.{js,html,less} 不止是为了方便组件加载，也方便组件代码查看，所有组件的 JS、模板、Less 入口 文件都在这里，例如，可以把 index.less 写成：

@import 'base';
@import 'layer';
@import 'button';

这样即使代码拆掉了，也知道先从哪儿开始看。

[nuysoft]

@keyapril 增加额外的描述文件 info.json 可以附带和灵活扩展更多的信息，全部约定成 index.{js,html,less} 就断绝了表达更多信息的可能。

@dotnil 默认入口为与组件同名的文件本来也具备同样的功能。

个人认为目前做法的好处不够大到改变“关键文件的名称尽量与组件名活项目名保持一致”的习惯。

另外，目前组件库以自主开发为主，如果引入第三方组件就会面临因改名而必须重新测试的问题，会繁琐一些（阻力）。

[cyjake]

没看出来怎么会“断绝表达更多信息的可能”，如果是组件其他信息（版本、作者、仓库地址、演示地址什么的），我们已经有了 package.json ，而 JS、CSS 相关的，用 index.js 和 index.css 作为入口已经足够了。

加入 info.json 意味着多一次请求，和打包工作里多一次处理，而它的好处并没有多大。

要改成 pagination.js 和 pagination.css 也无不可，只不过重复一次组件名而已，但是真的没看出来 info.json 的必要。

[nuysoft]

@dotnil 补充，我理解的 info.json 等价于 package.json，因为引用了 SPM 源服务器，所以保留了 info.json 的称呼。

[cyjake]

那这里跟 index.{js,less} 的约束是不搭嘎的吧，Brix 里约定这个是为了组件的自动加载哇，感觉不是 SPM 里 info.json 所要解决的。