package规范review
errorrik opened this issue · comments
@leeight 已经review过了,求 @otakustay @firede @chriswong review
我有个问题,对于开发时的测试用例或示例:
对
内部模块依赖
,AMD Loader配置 必须(MUST) 将baseUrl
配置到${root}
下的src
目录,并且 不允许(MUST NOT) 通过paths
进行路径映射。
为什么不让 内部模块依赖
也通过 packages
的方式来配置呢?
我觉得这样更贴近真实的使用场景,并且更够更明显的将测试用例、示例代码与 package
本身的代码区分开来。
当业务系统就是不想让一个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更好
我觉得应该是不影响的(真是好奇怪的需求),我的意思是,假设在 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')
的方式引用当前开发的包,与正常的使用场景一致。
哦这个意思,我还以为是在er/Action
中要使用自己的controller
得写成require('er/controller')
……看来是理解错了
上面说的package
的配置方式我也蛮赞同的,话说esui好像用的就是这种
嗯嗯,所以我觉得 依赖管理
描述 测试用例
或 示例
的部分时:
对内部模块依赖,AMD Loader配置 必须(MUST) 将baseUrl配置到${root}下的src目录
这个有些太严格了。
location: '../dep/er-route/0.8.0/src'
写错了吧?
对内部模块依赖,AMD Loader配置 必须(MUST) 将baseUrl配置到${root}下的src目录
对外部包依赖的情况,require依赖引用 必须(MUST) 使用top-level id。
这个没有限制不能用packages呀?
写错了吧?
唔,笔误~
这个没有限制不能用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'
]
AMD Loader 将 baseUrl 配到 ${root}/src 有点别扭呀。
如果是module.conf
里面这么配置,应该就能说得过去了。其它*.html
,如果使用的edp add html foo.html
,那么页面里面的baseUrl
其实是根据module.conf
里面的配置算出来的。
赞 @firede 的发现。那改成下面这样如何?
开发时,我们通常会做一些测试用例或示例,此时需要通过AMD Loader将当前包粘合到页面环境,并使其可运行。这时我们需要遵守一些规则:
- 对
内部模块依赖
,AMD Loader配置 推荐(RECOMMENDED) 通过packages
将location
配置到${root}
下的src
目录, 不允许(MUST NOT) 通过paths
进行路径映射。 - 对
外部包依赖
,请参照项目目录结构规范将相关依赖包导入,并且 必须(MUST) 通过packages
项配置AMD Loader。
如果是module.conf里面这么配置,应该就能说得过去了。其它*.html,如果使用的edp add html foo.html,那么页面里面的baseUrl其实是根据module.conf里面的配置算出来的。
@leeight package我觉得应该不会按照biz project那样开发的,所以,package开发应该不会搞出个module.conf来,通常example或者test的配置会手贱。手贱=手建
可选字段增加 peerDependencies 吧?
经过讨论,是frontend package,不需要+peerDependencies。
close了
@leeight package我觉得应该不会按照biz project那样开发的,所以,package开发应该不会搞出个module.conf来,通常example或者test的配置会手贱。手贱=手建
貌似以前讨论过:ecomfe/edp#127