杂谈（其一） | Saika's Blog

最近在几个仓库的使用上遇到了一点点小的问题，在解决问题的过程中，顿感 GitHub 的搜索功能之好用与强大，现来记一笔流水账。

本来放着不需要管的 New-API-FreeBSD 仓库突然 workflow 运行失败了，我一检查，有如下错误：

/home/runner/work/new-api-freebsd/new-api-freebsd/new-api/web/node_modules/rollup/dist/native.js:38
  	throw new Error(
  	      ^

  Error: Your current platform "freebsd" and architecture "x64" combination is not yet supported by the native Rollup build. Please use the WASM build "@rollup/wasm-node" instead.

  The following platform-architecture combinations are supported:
  android-arm
  android-arm64
  darwin-arm64
  darwin-x64
  linux-arm
  linux-arm64
  linux-arm64 (musl)
  linux-riscv64
  linux-x64
  linux-x64 (musl)
  win32-arm64
  win32-ia32
  win32-x64

  If this is important to you, please consider supporting Rollup to make a native build for your platform and architecture available.

然后我便去查看了 New-API 的源仓库，发现其前端从 React 换成了 Vite 。而 Vite 在构建时需要使用 Rollup ，而 Rollup在构建时就有了如上报错。当然， Rollup 很贴心的给出了替代的解决方案——使用 @rollup/wasm-node 。

但是很不巧的是，我对 JavaScript 一窍不通，我根本不知道如何使用 @rollup/wasm-node 。即便我去其仓库看 README ，也完全摸不着头脑。

于是我直接在 GitHub 搜索报错信息，然后在 Nuxt 的 issue 里发现了解决办法——荷兰开发者 pi0 给出了可行的解决办法：

You can use resolutions field in package.json (works with pnpm, yarn and recent npm, alternatively you can use overrides if not works) to pin to use wasm version of SWC:
1
2
3
4
5
6
"resolutions": {
"rollup": "npm:@rollup/wasm-node"
},
"overrides": {
"rollup": "npm:@rollup/wasm-node"
},

于是我尝试使用 jq 命令直接在前端部分的 package.json 中添加上述字段：

1	cp package.json package.json.bak && jq '.resolutions = {"rollup": "npm:@rollup/wasm-node"} \| .overrides = {"rollup": "npm:@rollup/wasm-node"}' package.json.bak > package.json

然后重新构建并测试，完全正常。

由于 GitHub Copilot 的审查愈发严格，转 API 使用下封号速度越来越快，而 OpenAI 方的反逆向也愈演愈烈，不论是 Cloudflare 的五秒盾还是 OpenAI 的 Arkose Token 的加入，方便免费的使用 ChatGPT 变得愈加困难。

~~病急乱投医下~~我希望增加一些能够继续便利使用 GPT API 的渠道，然后我发现了deanxv/coze-discord-proxy。简单看下来（主要是看 Dockerfile 和 docker-compose.yaml ），在 Linux 上的使用，问题最大的应该是 Discord 和 Coze 机器人的账号，应用本体的部署是非常的简单易用的，等我真的要部署的时候再来看也不急，那么先折腾一下 FreeBSD 版本吧。

又由于其 Dockerfile 内的构建本体的步骤异常的简洁，于是我很快就写好了 workflow ，构建好了 FreeBSD 的版本（实际上如果作者愿意也可以直接使用 go build 的交叉编译啦，但是我不好意思打扰人家）。

然后就丢给论坛里的热佬去测试了。但是很快，就传来了在 Serv00 上因为权限不足不能访问 /tmp 目录，无法运行的消息：

1
2

[烫烫烫烫@s2]:<\~/domains/coze2api>\$ ./start.sh
[FATAL] 2024/03/25 - 09:46:37 | [open /tmp/data-gym-cache/9b5ad71b2ce5302211f9c61530b329a4922fc6a4.1d1adbda-d03c-46cc-b006-7353d3de07b3.tmp: permission denied]

我一看，第一想法是在源仓库内搜索 data-gym-cache 字段，看看具体的代码是怎么写的，此路径是否可以通过变量调整。结果当然是什么也没搜到。

虽然我不会 golang ，但是也用了不少 golang 写的应用，没见过猪跑也吃过猪肉是不是，我当然知道 golang 在构建前要先 go mod download ，即下载 go.mod 文件中标明的依赖项。

也就是说，/tmp/data-gym-cache 路径并非 deanxv/coze-discord-proxy 规定的，而是其依赖规定的。但是 go.mod 中又有那么多的依赖，我该怎么查找呢？

幸运的是，deanxv/coze-discord-proxy 的所有依赖项都是 GitHub 上的，所以我直接在 GitHub 搜索 data-gym-cache ，查看 code type ，看到了原本的依赖中，是用 DATA_GYM_CACHE_DIR 为变量名设置缓存目录的，而 /tmp/data-gym-cache 是其默认值。所以我告诉论坛热佬，设置这个变量为他有权限访问的路径，然后就运行成功了。

同理，我尝试在 Serv00 上使用 WarpGPT，也遇到了这个无权限访问 /tmp 路径的问题，根据其具体文件名称查询，是 eddycjy/fake-useragent 这个六年前就停止维护的库的问题，通过更改变量名 TMPDIR 的值可以更换其缓存目录，以达到在 Serv00 上正常使用的目的。

以上经历令我对 GitHub 的搜索功能有了进一步的认识，不得不说这也是一个解决问题的重要工具，因为其搜索范围涵盖 Code、Repositories、Issues、Pull requests、Discussions、Users、Commits、Packages、Wikis、Topics、Marketplace 等多个方面，可以使用任意一点已知信息获取到许许多多的相关信息，不仅仅是仓库功能的介绍，还包括问题的解决方法和代码的实现方法等等。在此我作一个暴论：用好 GitHub 的搜索引擎，能够极大地提高学习效率。