关于 Electron App 代码管理的思考

引子

最近部门在推进 electron base 的 app 开发。 之前我们采用 electron-builder 做构建，但是由于它不支持客制化 file description，所以我的一个同事开发了一个支持 file description 的程序（包装了 electron-packager）来取代之前的配置（其实我觉得提一个 requet 给 electron-builder 会更好）。后来不知什么时候，这个小程序又被迫必须支持从 Jenkens 抽取版本号。同事很头疼，我们就聊了一会。也就有了下面的一些思考。

构建

目前构建走的的是 Jenkens。 从 Jenkens 选择项目构建，后台会从代码仓库拉最新的主分支代码下来，然后安装依赖，依次编译（包括编译web资源，比如 es2015代码，scss， react 代码），打包（electron-builder）。总共下来，需要花费大约八分钟。

下载代码 -> 安装依赖 -> 编译（es2015, react, scss etc）-> 打包为可执行文件

下面是几个我觉得还有优化空间的地方。

• 下载代码

代码中包含大量的 dll，下载花费的时间较长且本身更新频率并不高，我建议在 server 中维护一个 git repo，用 git pull 代码代替直接下载。

• 安装依赖

依赖中包含很多开发(dev)工具，比如各种 hot-loader 和 middleware，这些包对构建(production)毫无用处。如果可以忽略再好不过。

一般在 package.json 中，构建工具例如 gulp 都会加入 devDependencies 中，下面的命令不会安装 devDependencies

npm install --only=production

但是这样做是有问题的，gulp 不会被安装了，那么，构建也就无法谈起。所以要区分开发工具和构建工具。比如： react-hot-loader 就是开发工具，css-loader 就是构建工具。也就是说，原本对于 dependencies 和 devDependencies 的定义方式，我们要重新规划。

扯远了，目前看起来，优化空间是有，但是想法还不够成熟。

版本号管理

PO 希望构建的项目的版本号从 Jenkens 中抽取，这就需要项目在构建过程中分析 Jenkens 提供的一个链接，从中抽取版本号，然后加入项目。这样带来一个问题就是，同样的代码可能打包出两个版本号不同的安装包。而且也无法知道安装包对应到代码的具体版本，也就无法在 bug 出现的时候做 hot fix。如果非要维护这样的关系也不是不可以，那就要额外加入版本映射了。

我认为版本号还是应该和代码绑定在一起，即，代码中就预先配置好版本号，譬如在 package.json 的 version 字段中配置当前的版本号。这样如果有线上 bug 的话，也方便做 hot fix。当然 Jenkens 可以提供类似版本名这样的东西，作为一个可选的配置项，存在于安装包之中。比如这样。

config.ini

version_name=alpha

程序可以根据需要，读取并呈现。

（未完待续）