package规范review

[Erik]

@leeight 已经review过了，求 @otakustay @firede @chriswong review

new
审审看有没问题，修改了“包开发说明”部分。老版本在这里：
old

[Zhao Lei]

我有个问题，对于开发时的测试用例或示例：

对内部模块依赖，AMD Loader配置 必须(MUST) 将baseUrl配置到${root}下的src目录，并且 不允许(MUST NOT) 通过paths进行路径映射。

为什么不让 内部模块依赖 也通过 packages 的方式来配置呢？
我觉得这样更贴近真实的使用场景，并且更够更明显的将测试用例、示例代码与 package 本身的代码区分开来。

[Gray Zhang]

当业务系统就是不想让一个package保持它原来的名字（别问为啥，有人蛋疼）时，对于package依赖的其它package名字，可以通过map（假设loader支持）来配置的：

{
    packages: [
        // 爷就是不想让ER叫ER
        {
            name: 'zr',
            location: 'dep/er/3.1.0/src'
        },
        // 这样的话别的模块依赖ER会出错
        {
            name: 'er-route',
            location: 'dep/er-route/0.8.0/src'
        }
    ],
    map: {
        // 但是用map能拯救世界
        'er-route': {
            'er': 'zr'
        }
    }
}

但是package自己，作为入口的模块，map好像是救不了的，会出现各种问题，所以package里用relative id更好

[Zhao Lei]

我觉得应该是不影响的（真是好奇怪的需求），我的意思是，假设在 er-route 的包中需要依赖 er，那么在 er-route 这个包的 测试用例 和 示例 中可以这样配自己：

// demo/example.html
packages: [
    // 定义正在开发的package
    {
        name: 'er-route',
        location: '../src'
    },
    // 依赖的package就算改名叫zr，也照样可以map
    {
        name: 'er',
        location: '../dep/er-route/0.8.0/src'
    }
]

这是在 package 的测试用例和示例，不会被这个package以外的地方引用。在 src 下仍然是 relative id 的形式。

好处是在示例的代码中会通过 require('er-route') 的方式引用当前开发的包，与正常的使用场景一致。

[Gray Zhang]

哦这个意思，我还以为是在er/Action中要使用自己的controller得写成require('er/controller')……看来是理解错了

上面说的package的配置方式我也蛮赞同的，话说esui好像用的就是这种

[Zhao Lei]

嗯嗯，所以我觉得 依赖管理 描述 测试用例 或 示例 的部分时：

对内部模块依赖，AMD Loader配置 必须(MUST) 将baseUrl配置到${root}下的src目录

这个有些太严格了。

[Li YuBei]

location: '../dep/er-route/0.8.0/src'

写错了吧？

---

对内部模块依赖，AMD Loader配置 必须(MUST) 将baseUrl配置到${root}下的src目录
对外部包依赖的情况，require依赖引用 必须(MUST) 使用top-level id。

这个没有限制不能用packages呀？

[Zhao Lei]

写错了吧？

唔，笔误~

这个没有限制不能用packages呀？

在 test 和 demo 中，AMD Loader 将 baseUrl 配到 ${root}/src 有点别扭呀。

举一个真实场景的例子：https://github.com/ecomfe/er/blob/master/demo/book-store/main.htm

这个页面的 baseUrl 若配成 ${root}/src，那 global require 的依赖会变成：

[
    'er', 'er/tpl', 'er/events', 'er/ajax',
    'er/Deferred', 'er/template', 'er/config',
    '../demo/book-store/common/database', '../demo/book-store/book/init', '../demo/book-store/cart/init', '../demo/book-store/common/init'
]

而原来是：

[
    'er', 'er/tpl', 'er/events', 'er/ajax',
    'er/Deferred', 'er/template', 'er/config',
    'common/database', 'book/init', 'cart/init', 'common/init'
]

[Li YuBei]

AMD Loader 将 baseUrl 配到 ${root}/src 有点别扭呀。

如果是module.conf里面这么配置，应该就能说得过去了。其它*.html，如果使用的edp add html foo.html，那么页面里面的baseUrl其实是根据module.conf里面的配置算出来的。

[Erik]

赞 @firede 的发现。那改成下面这样如何？

开发时，我们通常会做一些测试用例或示例，此时需要通过AMD Loader将当前包粘合到页面环境，并使其可运行。这时我们需要遵守一些规则：

1. 对内部模块依赖，AMD Loader配置 推荐(RECOMMENDED) 通过packages将location配置到${root}下的src目录， 不允许(MUST NOT) 通过paths进行路径映射。
2. 对外部包依赖，请参照项目目录结构规范将相关依赖包导入，并且 必须(MUST) 通过packages项配置AMD Loader。

如果是module.conf里面这么配置，应该就能说得过去了。其它*.html，如果使用的edp add html foo.html，那么页面里面的baseUrl其实是根据module.conf里面的配置算出来的。

@leeight package我觉得应该不会按照biz project那样开发的，所以，package开发应该不会搞出个module.conf来，通常example或者test的配置会手贱。手贱＝手建

[Zhao Lei]

@errorrik 可以，我没问题了~

[dafo]

可选字段增加 peerDependencies 吧？

[Erik]

经过讨论，是frontend package，不需要＋peerDependencies。
close了

[Li YuBei]

@leeight package我觉得应该不会按照biz project那样开发的，所以，package开发应该不会搞出个module.conf来，通常example或者test的配置会手贱。手贱＝手建

貌似以前讨论过：ecomfe/edp#127