node.js生成可执行文件

将node创建的服务打包成可执行的exe文件

故事背景

为什么我要将node.js创建的服务打包成exe文件呢？主要是我对接的后端经常性的、偷摸的修改接口和接口返回的数据解构。并且他还很拽，总觉得前端就是切图仔。对此我怀恨在心已久，所以我准备使用node.js自己连接数据库，并使用pkg打包成一个后端同名的服务。在下一次组内冒烟的时候教训一下这个家伙，但是在使用pkg打包node.js应用程序的时候遇到了一些问题，这篇文章将使用过程中的坑记录下来，方便有缘人。

写在最前面

本文所有命令都是在git自带的终端bash中执行的。

生成项目解构

mkdir test-pkg
cd test-pkg
yarn init -y
touch server.js
yarn add pkg

使用node.js创建接口服务器

// server.js
const http = require('http');

const server = http.createServer((req, res) => {
    if (req.url === '/api') {
        res.setHeader('Content-Type', 'application/json');
        res.end(JSON.stringify({
            data: true
        }));
    } else {
        res.statusCode = 404;
        res.end();
    }
});

server.listen(3000, () => {
    console.log('Server is running on port 3000');
});

修改package.json中的内容

{
  "name": "test-pkg",
  "version": "1.0.0",
  "main": "server.js",
  "license": "MIT",
  "scripts": {
    "start": "node server.js",
    "build": "pkg server.js --target win --output Faker.exe"
  },
  "dependencies": {
    "pkg": "5.8.1"
  }
}

其中，server.js就是打包入口，Faker.exe就是打包生成的可执行文件的名称。

尝试打包

yarn build

处理报错

果不其然报错了：

$ yarn build
yarn run v1.22.19
$ pkg server.js --target win --output VxFaker.exe
> pkg@5.8.1
> Fetching base Node.js binaries to PKG_CACHE_PATH
  fetched-v16.16.0-win-x64            [                    ] 0%> Not found in remote cache:
  {"tag":"v3.4","name":"node-v16.16.0-win-x64"}
> Building base binary from source:
  built-v16.16.0-win-x64
> Fetching Node.js source archive from nodejs.org...

了解错误

1. Fetching base Node.js binaries to PKG_CACHE_PATH 这句中有两处需要注意，一个是 ① Node.js binaries，另外一个是 ② PKG_CACHE_PATH
2. fetched-v16.16.0-win-x64 [ ] 0%> Not found in remote cache: 这句中，③ fetched-v16.16.0-win-x64好像是要下载的一个文件，④ remote cache好像是下载的目的地。
3. {"tag":"v3.4","name":"node-v16.16.0-win-x64"} 这句中的 ⑤ "tag":"v3.4"和 ⑥ "name":"node-v16.16.0-win-x64"好像是资源的信息。

分析错误

1. Node.js binaries实际上是使用pkg打包的时候依赖的node.js的二进制文件，就是字面意思。由于公司开发机没有连接外网，所以这个依赖下载失败了，需要手动去github上下载;
2. PKG_CACHE_PATH这个则是node缓存的地址，使用echo $PKG_CACHE_PATH查看此地址，如果返回为空，则使用bash命令手动设置一下，现在先假设其为A;
3. fetched-v16.16.0-win-x64这个是依赖的名称，从github上手动下载依赖之后，需要将资源的名称修改成fetched-v16.16.0-win-x64;
4. remote cache我们现在要手动下载了，不需要remote cache了。实际上，如果PKG_CACHE_PATH中能够找到fetched-v16.16.0-win-x64这个文件，就不需要再去remote cache下载了;
5. "tag":"v3.4"这个实际上是告诉你fetched-v16.16.0-win-x64不是放在A 下面的，而是A的子目录，即A/v3.4中;
6. "name":"node-v16.16.0-win-x64"这个实际上是在告诉你，要去github上找这个文件。然后改名为fetched-v16.16.0-win-x64。

【解决疑问】为什么是v16.16.0，实际上，这个版本号对应的正是适用当前使用的node版本的二进制文件的版本号，在终端使用node -v即可查看当前node的版本号：

$ node -v
v16.20.1

逐个击破

1. github上的下载地址为：https://github/vercel/pkg-fetch
2. 如果echo $PKG_CACHE_PATH的结果不为空，则找到此目录（A）,在A下面创建名为v3.4 的子目录；如果为空，则先使用执行~/.pkg-cache，得到结果为：/c/Users/zhangsan/.pkg-cache；然后手动设置PKG_CACHE_PATH的值，export PKG_CACHE_PATH="C:\\Users\\zhangsan\\.pkg-cache",然后在C:\\Users\\zhangsan\\.pkg-cache下面创建子目录v3.4
3. 通过{"tag":"v3.4","name":"node-v16.16.0-win-x64"}中的v3.4和node-v16.16.0-win-x64两个线索，在https://github/vercel/pkg-fetch找到对应的资源并下载下来，保存到A/v3.4目录中，然后改名为fetched-v16.16.0-win-x64

再次尝试

yarn build

结果会在当前项目的根目录下生成VxFaker.exe可执行文件，大功告成！

后续

期待这个夸张的后端看到自己的服务在冒烟机上正常，在自己机子上无法返回数据的表现吧，那么他是苟起来当作无事发生，还是一脸茫然呢？评论区留言，让大家都笑一笑他吧~