-
Notifications
You must be signed in to change notification settings - Fork 2
编译与构建功能设计
goto100 edited this page Mar 12, 2013
·
1 revision
- 更加多样的开发模式选择;
- 更加自动化的开发、调试、发布流程;
- 源库,拥有package.json的一个opm所维护的代码库;
- 目标库,是将源库通过一些列的规则配置构建出来独立的目录空间,一个源库可以产生多个目标库;
使用package.json获取依赖库等配置信息,将opm特有的配置放在opm对象下。
通过 package.json 中的配置项,将多个文件合并成一个。
- 支持递归合并,保证文件最小颗粒度;
- 支持模块合并,通过指定所使用的js loader,自动为合并后的js文件加上define包裹,至少支持RequireJS、SeaJS的loader;
- 支持基于loader的自动合并配置,通过查找js的依赖配置信息,自动合并其余所需模块,支持过滤;
配置举例:
{"opm":
"combines": {
"a.js": [ // 以下4个文件合并出 a.js
"b.js", // 一个普通的js,原文拷贝
"module:c.js", // 一个js模块,根据loader配置加上define包裹
"module:d.js?dependencies=all", // 一个js模块,将此文件的所有依赖都合并进来
"module:e.js?dependencies-level=1", // 只将一级依赖的文件合并进来
"f.coffee" // 一个coffee文件,将编译后的 .js 文件合并进来
],
"aa.js": ["a.js", "a2.js"] // 合并一个合并文件a.js和一个普通文件a2.js
}
}
自动将css中的import文件合并至当前文件。
支持 less、coffee 等语言的编译。可同时搭配文件合并功能使用。
源库与目标库是一对多的关系,在构建过程中,源库仅提供基本的构建配置信息,每个目标库可以自行提供针对自己的配置信息,这是bpm的一个独特设计,可以避免源库配置信息过大且在特定生产环境下无效配置信息过多的问题。比如:
- cdn上只需要保存有发布库的构建设置,无需保存开发库的构建设置;
- jsp开发人员只需要保存模版文件相关的配置信息,无需保存其他静态文件的构建设置。
这个设计使得bpm可以发展为不仅仅为前端静态文件开发提供服务的构建工具,其可以发展为前端开发与后端开发接口部分的构建工具,甚至专门针对后端的构建工具,成为真正的通用构建工具(长远目标)。
TODO: 例子图
由于一对多的关系,只能通过目标库找到源库,而无法通过源库找到目标库。目标库中会通过信息文件(.opm目录中)保存源库的本地磁盘路径,从而找到源库。通过命令 opm link
、opm source
可自动化此过程。