共计 1771 个字符，预计需要花费 5 分钟才能阅读完成。
背景
当初，EggJS被许多开发团队所采纳。有的团队基于 商业知识产权 的考量，往往会提一个问题：是否能够把 EggJS 当中的代码编译打包，而后再把代码美化？
模块编译的机制
EggJS为何不能便当的实现编译的个性？
在 EggJS 中，代码文件都是通过 约定代码地位 的形式组织并加载的。也就是说，代码文件都搁置在约定的目录构造当中，EggJS 在启动零碎时，在约定的地位扫描加载约定的代码文件。因而，在这种机制下，不能便当的实现编译个性
CabloyJS是如何实现编译个性的？
EggJS作为企业级框架提供了足够灵便的机制，比方，容许 下层框架 提供自定义的 加载器 。CabloyJS 就是基于 EggJS 的这种机制实现了一套自定义的加载器
在 CabloyJS 中，模块当中的代码文件都是通过 require 的形式 显式 组织并加载的。这种加载机制为模块外部的源码文件提供了清晰的调用依赖关系，因而咱们就能够采纳 Webpack 实现编译打包，以及美化代码的工作
模块编译的意义
模块复用、构建生态：模块可独自编译，从而能够独自公布、独自部署，独自降级，从而促成 CabloyJS 整个生态圈的凋敝，进一步减速理论业务的开发知识产权：模块可独自编译，也能够满足爱护商业代码的需要
如何编译模块
# 进入模块所在目录
$ cd /path/to/module
# 编译模块前端代码
$ npm run build:front
# 编译模块后端代码
$ npm run build:backend编译参数
所有模块均采纳缺省的编译参数，当然也能够提供自定义的编译参数，以模块 test-party 为例：
src/module/test-party/build/config.js
module.exports = {
front: {
productionSourceMap: false,
uglify: true,
},
backend: {
productionSourceMap: false,
uglify: true,
},
};| 名称 | 阐明 |
|---|---|
| productionSourceMap | 是否生成 SourceMap 文件 |
| uglify | 是否 uglify 代码 |
模块加载约定
在模块目录下，既有 src 源代码文件，也有 dist 打包文件。那么什么时候加载 src，什么时候加载dist 呢？
模块有两类：全局模块 和部分模块。这两类模块有不同的加载约定：
全局模块：位于我的项目的node_modules目录中，零碎总是加载全局模块的dist打包文件部分模块：位于我的项目的src/module目录中，零碎优先查找src目录并加载模块源码，如果没有找到则加载部分模块的dist打包文件
了解了
全局模块与部分模块的代码加载约定，在将我的项目部署在生产环境时有利于做出正确的配置（次要的诉求就是：如何爱护商业代码）
最佳实际（模块前端）
在部署时，我的项目前端总是要进行 整体编译 ，把所有 全局模块 和部分模块 的前端源码和前端资源都打包，而后输入到我的项目的 dist 目录
如果模块作为 部分模块 而存在，则不须要思考模块前端的编译环节
如果模块要公布为 全局模块，则必须先进行模块前端的编译
最佳实际（模块后端）
1. 不进行模块编译
如果没有 爱护商业代码 的需要，那么就不必思考模块编译的环节。在部署时，间接作为 部分模块 加载源码运行即可
2. 进行模块编译
如果要进行模块编译，那么在部署时有两个抉择：
-
作为部分模块
- 模块依然位于我的项目的
src/module目录 - 将模块编译后，在生产环境删除模块的
src源码目录即可
- 模块依然位于我的项目的
-
作为全局模块
- 将模块编译后，公布至公司的公有仓库
- 在我的项目中将模块作为
全局模块装置至node_modules目录 - 如果没有公有仓库，也能够采纳
npm link机制装置为全局模块
模块公布
当我的项目中的模块代码稳固后，能够将模块公开公布，奉献到开源社区。也能够在公司外部建设 npm 公有仓库，而后把模块公布到公有仓库，造成公司资产，便于重复使用
$ cd /path/to/module
$ npm run build:front
$ npm run build:backend
$ npm publish因为公布到 npm 仓库的模块将作为
全局模块来应用，因而须要先编译模块的前端和后端
效果图（模块后端编译）
编译之前的源码构造
编译之后的输入文件
相干链接
- 官网: https://cabloy.com/
- GitHub: https://github.com/zhennann/cabloy