模块组织粒度问题

[shaoshuai0102]

像arale.array，arale.dom等模块应该如何组织？

• 方案一 这些模块不使用define这种commonJS形式规范来组织，只是维护上分为独立模块，把这些全部打包后，arale作为一个整体来向外发布。jQuery采用这种做法。
• 方案二 所有模块严格按照commonJS规范组织，是用define定义模块，通过exports或return向外暴露API，为了别人使用方便，最后通过arale.core这个模块把其他模块require进来后，进行整体命名空间和API的暴露。这样会让每个模块比较纯粹，但也会有代码冗余。

针对现在已经改动的模块，存在以下问题：

• 使用define定义模块，但部分API的暴露还是通过向arale这个对象上挂载来实现的。

我的观点，要么直接不使用define，把代码整好，最后整个arale通过一个define来完成模块的封装，要么使用define，每个模块都严格遵循规范，为了达到与现在兼容，在arale.core进行组装，API封装等。

倾向于第二种。

[leoner]

_使用define定义模块，但部分API的暴露还是通过向arale这个对象上挂载来实现的_ 这个完全是为了兼容性考虑的, 后续肯定不会这样做的. 因为现在不能消除其他代码对全局变量的引用, 所以原有如果污染全局变量的方法和接口并没有给限制死, 但是我们内部的引用一定严格的按照require的方式来. 不能直接引用全局变量了.

[lifesinger]

我推荐采用方案二，可以看 1.2 中 dom 和 event 的组织 CommonJS 支持子模块开发方式，好处很明显：

1. 子模块也是模块，无任何特殊性，遵循的规范一模一样
2. 父模块里，声明了所依赖的子模块，任何子模块则只依赖父模块，看似循环依赖，其实 CommonJS 规范是支持循环依赖的，这种子模块拆分方式，目前在 YUI3 和 KISSY 里都有使用，很成熟
3. 依赖打包等信息，存在于 js 代码本身里，不需要起来 Ant 或 Maven 的配置，保证了内聚和完备性

大家先看看 1.2 的代码？

[leoner]

还有就是目前有些代码不光是直接引用arale.core, 有些是从arale.base开始引入的, 所以如果我们把某些对全局变量进行污染的模块给封装起来的话, 就不能保证这些项目的安全使用了. 所以我目前的想法是如果是对现有模块改造的话, 那么我们两种都可以支持, 但是我们可以通过其他手段(代码扫描)等方式协助用户在产品开发中去掉对全局变量的引用, 改为require的方式进行引用. 等到产品全部升级完毕后, 我们在把全局变量给去掉.

[lifesinger]

基本已达成一致，采用 CommonJS 的方式，彻底模块化。

Arale 1.x 的问题，等以后需要做兼容层时再考虑。