在gitlab上发布npm二进制文件

❝
允许奇迹发生
❞

大家好，我是「柒八九」。一个「专注于前端开发技术/Rust及AI应用知识分享」的Coder。

前言

还记得之前我们讲过如何在 npm 上发布二进制文件？吗。我们通过npm将我们之前在Rust 赋能前端-开发一款属于你的前端脚手架中生成Rust二进制文件发布到npm仓库中。

如果想体验上述功能，可以通过npm全局安装f_cli_f^[1]在本地体验一下。

如果，你不想把自己的npm发布到公网上，那么我们还可以将我们的npm发布到公司内网上。这个我们在如何在gitlab上发布npm包介绍过了。

但是呢，在如何在gitlab上发布npm包中我们只是介绍了如何发布一个正常的npm，并且还不涉及各个包直接的关联。如果，我们想在gitlab发布二进制类型的包，同时还涉及多个包直接的交互呢，上面的方案就有点捉襟见肘了。

那么，我们今天就聊聊，如何在「gitlab发布npm二进制包」并且我们还会涉及npm包直接的互相操作。

好了，天不早了，干点正事哇。

我们能所学到的知识点

❝

项目结构

发布子包到gitlab 仓库

主包逻辑

全局安装并执行
❞

1. 项目结构

我们采用和之前发布到npm的目录结构几乎一样。

有四个包

f_cli_windows_x64: f_cli 适配 Windows架构
f_cli_darwin_x64: f_cli 适配 MACOS_Intel64架构
f_cli_darwin_arm64: f_cli适配 MACOS_ARM64架构
f_cli:主包，用户根据用户操作环境下载对应的二进制文件

2. 发布子包到 gitlab 仓库

子包有3个，分别针对我们常见的开发环境。其实它们的内容极其简单。这个和之前在如何在 npm 上发布二进制文件？中是一样的。

"f_cli_darwin_arm64"/"f_cli_darwin_x64"
 ├── package.json
 └── bin/
     └── f_cli

"f_cli_windows_x64"
 ├── package.json
 └── bin/
     └── f_cli.exe

在bin文件中存放的就是我们脚手架编译后的二进制文件。

❝
由于这三个子包的处理方式都出奇的一致。我们就随意挑选一个来讲解
❞

创建.npmrc

在如何在gitlab上发布npm包讲过，如果要在gitlab发布npm私包，我们需要创建一个.npmrc。

@<your-scoop>:registry=https://公司gitlab域名/api/v4/npm/
//公司gitlab域名/api/v4/projects/<your_project_id>/packages/npm/:_authToken=${AUTH_TOKEN}`

❝
当然，我们还需要在gitlab中构建一个空项目，这步就省略了。
❞

上面有几个参数我们需要变更

<your-scoop>:这里设置我们的想要的名称，这里我们设置为 cli
<your_project_id>:这是我们 demo项目在 gitlab的id,这个我们可以在 Settings->General->Project ID获取
AUTH_TOKEN我们使用环境变量来处理，这个变量在主页面的 Settings->Repository->Deploy tokens中设置 token。

❝
别忘记，在生成token时，将值保存起来。
❞

修改package.json

我们在package.json中还需要新增publishConfig,这是用于npm publish时用的。

{
  //...
  "publishConfig": {
    "@cli:registry": "https://公司gitlab域名/api/v4/projects/project_ID/packages/npm/"
  }
}

发布包

最后，我们使用

AUTH_TOKEN=XXX npm publish

将本地的二进制包发布到了gitlab。可以看出，我们使用的手动发布的方式。是因为，我们这三个子包其实内部没啥逻辑，只是一个二进制文件，所以我们就选择了用「手动发布」的方式。

随后，我们就可以在demo项目中的Deploy->Package Registry中看到发布成功的包

3. 主包逻辑

下面到了我们这篇文章的核心部分。

其实，主包的目录结构也很简单。

新增.npmrc

还是一样的套路。

@<your-scoop>:registry=https://公司gitlab域名/api/v4/npm/
//公司gitlab域名/api/v4/projects/<your_project_id>/packages/npm/:_authToken=${AUTH_TOKEN}`

只不过需要将上面的信息，置换成主包的相关内容。

修改package.json

由于是主包，我们就需要额外的操作，这里就两点需要新增

bin
publishConfig

{
  "bin": {
    "front_cli": "bin/cli"
  },
  "publishConfig": {
    "@cli:registry": "https://gitlab.com/api/v4/projects/project_ID/packages/npm/"
  },
}

publishConfig就不用多说了，就是给npm发布用的。而bin中指定的信息就是,当此软件包「全局安装」时，该文件将链接到全局 bins 目录内，或者将创建一个 cmd（Windows 命令文件）来执行 bin 字段中的指定文件，因此可用于由 name 或 name.cmd（在 Windows PowerShell 上）运行。更过的可以参考package.json_bin^[2]

当然，如果我们使用像nvm/fnm等node版本管理工具的话，也会在指定的地方进行配置。最终的结果就是，可以使得我们的包能够在全局访问并且执行对应的命令。

由于，我们本机使用的是fnm，然后在主包被全局安装后，在对应的node文件夹中就会新增对应的信息。

bin/cli

这个和之前我们讲如何在 npm 上发布二进制文件？不同。

我们之前在package.json中还有

{
  "scripts": {
    "postinstall": "node ./install.js"
  },
}

也就是在包被安装后，会自动触发postinstall命令，执行node ./install.js。里面就是根据各种平台信息和对应包的下载。

下面是之前install.js的主要逻辑。 alt

但是呢，我们从本地安装发布到gitlab的私包时，它不触发postinstall的命令，也就是在主包下载后，无法下载对应的子包。那意味着我们的这个功能直接垮掉。

所以，我们索性取消掉postinstall的逻辑，将下载和执行二进制的路径都迁入到bin/cli中。

对比之前的install.js的逻辑，粗看下，其实没啥变化。主要流程还是根据process.platform和process.arch确定平台和架构，然后从BINARY_DISTRIBUTION_PACKAGES查找对应的信息。

BINARY_DISTRIBUTION_PACKAGES

由于我们发布的位置和名称也发生变化。这里的BINARY_DISTRIBUTION_PACKAGES也有些许变更。

const BINARY_DISTRIBUTION_PACKAGES = {
  'darwin-x64': '@cli/x64',
  'darwin-arm64': '@cli/arm64',
  'win32-x64': '@cli/windows_x64',
}

其实还有几点也发生了变化。之前我们是从npm中下载二进制包。由于我们在npm发布的公共包，也就意味着所有人都可以通过ajax进行获取。但是呢，我们现在也想通过ajax在node项目中获取gitlab私包。这就需要提供额外的信息。

projectID
授权信息

projectID被存放在了PROJECT_ID_MAP中。

const PROJECT_ID_MAP = {
  'darwin-x64': '1',
  'darwin-arm64': '2',
  'win32-x64': '3',
}

然后，授权就是我们在进行异步接口时候，需要通过header的Authorization字段提供。而这个字段的值就是之前我们申请的Deploy token（是不是让你保存了）。

我们之前提过，由于postinstall命令不好使，我们就把之前的install.js和bin/cli的逻辑合二为一了。

那就意味着现在bin/cli在被执行时，下载对应平台的二进制文件，并且根据参数执行命令。

downloadBinaryFromGitlab

这里我们分了两种情况

首次全局安装，那就需要下载对应的二进制文件并执行
非首次安装，那就直接执行对应的二进制文件就行。

剩余的逻辑和之前是一样的。

makeRequest

这里也是一个重点。

这里和之前的方法也有几点不同。

新增了 token参数
https新增了 options
根据数据返回的多少，显示了下载进度信息

先看makeRequest如何被调用。

const tarballDownloadBuffer = await makeRequest(
    `https://公司gitlab域名/api/v4/projects/${projectID}/packages/npm/${platformSpecificPackageName}/-/${platformSpecificPackageName}-${BINARY_DISTRIBUTION_VERSION}.tgz`,
    "glpat-xxx"
  )

我们来简单解释一下，由于我们现在是从gitlab拉取私库，都说了是私库，那势必就有鉴权处理。这里的token就是接收之前的Deploy Token。

然后，将接收到的token放到https的options的headers中。

针对这点，我们可以从gitlab官网^[3]查看。

针对进度信息的展示，也是很简单的逻辑，就是基于response的data事件，每次跟新downloaded，并且用process.stdout.write输出到控制台。

发布主包

虽然，主包看起来逻辑比较多，但是在发布时，也是一句话搞定

AUTH_TOKEN=XXX npm publish

随后，我们就可以在gitlab中看到发布的包信息了。

4. 全局安装并执行

既然，我们已经将主包发布到了gitlab，那我们就需要使用其他方式将其下载到本地，然后执行对应的命令。

修改全局.npmrc

之前的文章讲过，如果想要下载gitlab的私包，那就需要修改本地.npmrc和全局.npmrc。

因为，我们要全局安装，所以我们直接修改全局.npmrc。

使用open ./.npmrc打开.npmrc并加入如下命令

@cli:registry=https://公司gitlab域名/api/v4/projects/projectId/packages/npm
//公司gitlab域名/api/v4/projects/projectId/packages/npm/:_authToken=glpat-xxxx

大家根据自己的实际情况修改上述内容。

全局安装

在全局安装之前，我们可以使用npm list -g来看看自己在特定node环境下，全局安装了啥。

然后，我们使用npm i @cli/cli -g来全局安装。由于我本地已经安装过了，这里就不贴图了。

我们可以使用npm list -g来查看是否安装成功，亦或者直接在控制台中输入front_cli命令。

反正，只有不是提示没对应的文件那就是安装成功了。然后，我们就可以开开心心的使用这个命令了。

完美完结🎉🎉🎉🎉

后记

「分享是一种态度」。

「全文完，既然看到这里了，如果觉得不错，随手点个赞和“在看”吧。」

Reference

[1]

f_cli_f: https://www.npmjs.com/package/f_cli_f

[2]

package.json_bin: https://docs.npmjs.com/cli/v10/configuring-npm/package-json#bin

[3]

gitlab官网: https://docs.gitlab.com/ee/api/rest/#oauth-20-tokens

本文由 mdnice 多平台发布