將Node.js項目打包爲一個可執行文件。

Pkg
https://github.com/zeit/pkg
Pkg可將Node.js項目打包爲一個單獨的可執行文件，可在未安裝Nodejs的機器上運行。支持win、linux等多系統。

爲何使用pkg
Node.js應用不須要通過編譯過程，能夠直接把源代碼拷貝到部署機上執行，確實比C++、Java這類編譯型應用部署方便。然而，Node.js應用執行須要有運行環境，意味着你須要先在部署機器上安裝Node.js。雖然說沒有麻煩到哪裏去，但畢竟多了一個步驟，特別是對於離線環境下的部署機，麻煩程度還要上升一級。假設你用Node.js寫一些小的桌面級工具軟件，部署到客戶機上還要先安裝Node.js，有點「大炮打蚊子」的感受。更嚴重的是，若是部署機器上游多個Node.js應用，並且這些應用要依賴於不一樣的Node.js版本，那就更難部署了。

理想的狀況是將Node.js打包爲一個單獨的可執行文件，部署的時候直接拷貝過去就好了。除了部署方便外，由於不須要再拷貝源代碼了，還有利於保護知識產權。
固然打包也可能被破解的，若是打包前將nodejs源碼進行混淆加密，那就十分安全了。nodejs代碼加密，能夠用JShaman（http://www.jshaman.com/），簡單方便，很是不錯。

將Node.js打包爲可執行文件的工具備pkg、nexe、node-packer、enclose等，從打包速度、使用便捷程度、功能完整性來講，pkg是最優秀的。這篇文章就來說一講半年來我使用pkg打包Node.js應用的一些經驗。

pkg的打包原理簡單來講，就是將js代碼以及相關的資源文件打包到可執行文件中，而後劫持fs裏面的一些函數，使它可以讀到可執行文件中的代碼和資源文件。例如，原來的require('./a.js')會被劫持到一個虛擬目錄require('/snapshot/a.js')。

安裝
pkg既能夠全局安裝也能夠局部安裝，推薦採用局部安裝：

npm install pkg --save-dev

用法
pkg使用比較簡單，執行下pkg -h就能夠基本瞭解用法，基本語法是：

pkg [options] <input>

<input>能夠經過三種方式指定：

1.一個腳本文件，例如pkg index.js;
2.package.json，例如pkg package.json，這時會使用package.json中的bin字段做爲入口文件；
3.一個目錄，例如pkg .，這時會尋找指定目錄下的package.json文件，而後在找bin字段做爲入口文件。

[options]中能夠指定打包的參數：
1.-t指定打包的目標平臺和Node版本，如-t node6-win-x64,node6-linux-x64,node6-macos-x64能夠同時打包3個平臺的可執行程序；
2.-o指定輸出可執行文件的名稱，但若是用-t指定了多個目標，那麼就要用--out-path指定輸出的目錄；
3.-c指定一個JSON配置文件，用來指定須要額外打包腳本和資源文件，一般使用package.json配置。

使用pkg的最佳實踐是：在package.json中的pkg字段中指定打包參數，使用npm scripts來執行打包過程，例如：

{
 ...
 "bin": "./bin/www",
 "scripts": {
   "pkg": "pkg . --out-path=dist/"
 },
 "pkg": {
   "scripts": [...]
   "assets": [...],
   "targets": [...]
 },
 ...
}

scripts和assets用來配置未打包進可執行文件的腳本和資源文件，文件路徑可使用glob通配符。這裏就浮現出一個問題：爲何有的腳本和資源文件打包不進去呢？

要回答這個問題，就涉及到pkg打包文件的機制。按照pkg文檔的說法，pkg只會自動地打包相對於__dirname、__filename的文件，例如path.join(__dirname, '../path/to/asset')。至於require()，由於require自己就是相對於__dirname的，因此可以自動打包。假設文件中有如下代碼：

require('./build/' + cmd + '.js')
path.join(__dirname, 'views/' + viewName)

這些路徑都不是常量，pkg沒辦法幫你自動識別要打包哪一個文件，因此文件就丟失了，因此這時候就使用scripts和assets來告訴pkg，這些文件要打包進去。那麼咱們怎麼知道哪些文件沒有被打包呢？難倒要一行行地去翻源代碼嗎？其實很簡單，只須要把打包好的文件運行下，報錯信息通常就會告訴你缺失哪些文件，而且pkg在打包過程當中也會提示一些它不能自動打包的文件。

注意事項
若是說pkg還有哪兒還能夠改進的地方，那就是沒法自動打包二進制模塊*.node文件。若是你的項目中引用了二進制模塊，如sqlite3，那麼你須要手動地將*.node文件複製到可執行文件同一目錄，我一般使用命令cp node_modules/**/*.node .一鍵完成。可是，若是你要跨平臺打包，例如在windows上打包linux版本，相應的二進制模塊也要換成linux版本，一般須要你手動的下載或者編譯。

那爲何pkg不能將二進制模塊打包進去呢？我猜測是require載入一個js文件和node文件，它們的機制是不同的。另外從設計來講，不自動打包二進制模塊也是合理的，由於二進制模塊都是平臺相關的。若是我在windows上生成一個linux文件，那麼就須要拉取linux版本的.node文件，這是比較困難的。而且有些二進制模塊不提供預編譯版本，須要安裝的時候編譯，pkg再牛也不可能模擬一個其餘平臺的編譯環境吧。nexe能夠自動打包二進制模塊，可是隻能打包當前平臺和當前版本的可執行文件。這意味着若是Node.js應用引用了二進制包，那麼這個應用就不能跨平臺打包了，因此我認爲這方面，nexe不能算是一個好的設計。

還有一點就是關於項目中的配置文件處理，好比數據庫鏈接參數、環境變量等。由於這些配置文件會跟着不一樣的部署環境進行更改，因此爲了方便更改，通常不但願把配置文件打包到exe。爲了不pkg自動地將配置文件打包到exe中，代碼中不要採用如下方式讀取配置文件：

fs.readFile(path.join(__dirname, './config.json')), callback)

而是採用相對於process.CWD()的方法讀取：

fs.readFile(path.join(process.CWD(), './config.json'), callback)
// 或者
fs.readFile('./config.json', callback)

若是配置文件是js格式的，那麼不要直接require('./config')，而是採用動態require：

const config = require(process.CWD() + './config')

另外要說起的是pkg打包以後動態載入js文件會有安全性問題，即用戶能夠在js文件寫任何處理邏輯，注入到打包後的exe中。例如，能夠讀取exe裏面的虛擬文件系統，把源代碼導出來。因此，儘可能不要採用JS做爲配置文件，也不要動態載入js模塊。