十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

AIRI 单仓实践:pnpm CLI 核心命令全解(安装、脚本、Workspace、补丁与发布)

AIRI 单仓实践:pnpm CLI 核心命令全解(安装、脚本、Workspace、补丁与发布) AIRI 单仓实践pnpm CLI 核心命令全解安装、脚本、Workspace、补丁与发布【免费下载链接】airi Self hosted, you-owned Grok Companion, a container of souls of waifu, cyber livings to bring them into our worlds, wishing to achieve Neuro-samas altitude. Capable of realtime voice chat, Minecraft, Factorio playing. Web / macOS / Windows supported.项目地址: https://gitcode.com/GitHub_Trending/ai/airiAIRI 是一个横跨 Web、Electron、Android/iOS 的 pnpm monorepo根 package.json 通过packageManager字段锁定pnpm11.24.0。本文以仓库内的 pnpm CLI 参考文档 .agents/skills/pnpm/references/core-cli.md 为主体完整覆盖安装、脚本运行、workspace 过滤、补丁、全局包、运行时与发布等核心命令并结合 AIRI 仓库真实的 pnpm-workspace.yaml、package.json 与 CI 配置说明每条命令在大型单仓中的实际用法与约束。读完本文你可以直接使用这套命令管理 AIRI 这类多包仓库的依赖安装、构建编排与发布流程。安装命令从pnpm install到可复现的 CI 安装文档给出的基础安装命令集如下覆盖了添加、移除与更新依赖的日常操作pnpm install # 安装所有依赖别名pnpm i pnpm add pkg # 生产依赖 pnpm add -D pkg # devDependency也可用 -d pnpm add -O pkg # optionalDependency也可用 -o pnpm add -E pkg # 精确版本也可用 -e pnpm add pkgversion pnpm remove pkg # 别名rm、uninstall、un pnpm update # 别名up pnpm update --latest # 忽略 semver 范围-L pnpm update -i # 交互式更新干净/可复现安装文档专门列出了保证安装可复现性的四个命令pnpm install --frozen-lockfile # 若 lockfile 会变化则失败CI 中自动启用 pnpm ci # 干净安装 pnpm clean install --frozen-lockfile pnpm clean # 移除所有 workspace 项目的 node_modules别名purge pnpm clean --lockfile # 同时删除 pnpm-lock.yaml这一点在 AIRI 仓库有直接的落地证据.github/workflows/ci.yml 的 lint、build、test、typecheck 四个 job 中每个都显式执行pnpm install --frozen-lockfile如第 44、104、153、177 行保证 CI 安装结果与本地 pnpm-lock.yaml 完全一致构建阶段再配合pnpm run build:packages触发 turbo 的任务图构建。文档还特别强调了一个 v11 的行为变化自 v11 起tarball 与 lockfile 的完整性校验不匹配会直接报硬错误ERR_PNPM_TARBALL_INTEGRITY。只有在确认新字节内容无误后才使用pnpm install --update-checksums。在 CI 中pnpm 还会因 lockfile 由更新的 pnpm 主版本写就而失败。AIRI 根 package.json 第 6 行的packageManager: pnpm11.24.0正是配合这一约束的版本锚点CI 使用的pnpm/setupv2action 会依据该字段还原同一 pnpm 版本避免lockfile 版本高于 CI pnpm 版本导致的失败。脚本命令run、exec与 AIRI 的脚本编排文档给出的脚本命令集pnpm run script # 或直接pnpm script pnpm run build -- --watch pnpm run --if-present build pnpm set-script test vitest run # 添加/更新 scripts 条目别名ss pnpm exec cmd # 运行本地二进制如 pnpm exec eslint .文档同时指出两条容易踩坑的规则隐藏脚本以.开头的脚本名如.helper不能直接运行只能被其他脚本调用内建命令与脚本名冲突clean、setup、deploy、rebuild会优先执行package.json中的同名脚本若要强制执行内建命令需用pnpm pm name如pnpm pm clean。在 AIRI 根 package.json 中可以看到这套机制的典型用法postinstall脚本写作pnpm exec simple-git-hooks pnpm run build:packages——安装完成后自动注册 git hooks 并预构建全部基础包dev系列脚本则大量使用pnpm -rF proj-airi/pkg run dev的形式从根目录直达子包详见下文 Workspace 章节。dlx / pnx —— 免安装执行pnx create-vite my-app # pnx pnpm dlx pnpx pnpm dlx degit user/repo dest pnx shxcatalog: # 支持 catalog: 协议 pnx --packagescope/tool tool --helpdlx/pnx会遵循供应链设置minimumReleaseAge、trustPolicy并在 v11 中默认使用全局虚拟存储global virtual store。AIRI 仓库有两处印证根 package.json 第 50 行定义了nolyfill: pnpm dlx nolyfill用 dlx 临时拉取 nolyfill 工具无需将其写入 devDependenciespnpm-workspace.yaml 第 2 行的minimumReleaseAge: 4320正是文档提到的供应链策略配置——该仓库要求依赖包发布至少 3 天后才可被安装并对moeru/*、proj-airi/*等自有 scope 豁免见第 3-10 行的minimumReleaseAgeExclude。Workspace 命令与过滤模式AIRI 9 个目录族的构建编排文档给出的 workspace 命令pnpm -r run script # 在所有包中运行别名--recursive pnpm --filter pattern run script pnpm --filter ./packages/** run build pnpm --filter myorg/* run lint pnpm -r --parallel run dev过滤模式filter patternspnpm --filter pkg-name cmd # 按包名过滤-F 缩写 pnpm --filter ./packages/core test pnpm --filter ...scope/app build # 包 它依赖的包 pnpm --filter scope/core... test # 包 依赖它的包 pnpm --filter ...[origin/main] build # 相对 git 引用发生变化的包AIRI 仓库对这套机制的使用几乎覆盖了全部模式。pnpm-workspace.yaml 第 13-23 行声明了packages/**、plugins/**、integrations/**、services/**、examples/**、docs/**、engines/**、apps/**、server/**九个目录族并用!**/dist/**排除产物目录根 package.json 第 105-115 行的workspaces字段与之保持一致。在此基础上按 glob 路径过滤dev:apps: pnpm -rF\./apps/*\ run --parallel dev第 28 行同时演示了-rF缩写、glob 过滤与--parallel并行执行按包名过滤dev: pnpm -r -F proj-airi/stage-web dev第 16 行、dev:docs: pnpm -rF proj-airi/docs run dev第 17 行等十余个dev:*脚本均通过proj-airi/name包名精确指向单个子包多 glob 叠加typecheck: pnpm -rF\./packages/*\ -F\./apps/*\ -F\./server/**\ -F\./docs\ --parallel typecheck第 47 行在一次调用中覆盖四个目录族CI 中的单包构建.github/workflows/ci.yml 的 build-test job 用pnpm -F proj-airi/stage-web run build、pnpm -F proj-airi/stage-tamagotchi run build等命令按矩阵分别构建各应用第 56、59 行。值得注意的是AIRI 还叠加了 turbo 任务图根build脚本为turbo run build -F\./packages/*\ ...由 turbo.json 定义build任务的dependsOn: [^build]依赖拓扑。pnpm filter 负责选包turbo 负责排序与缓存两者组合是该仓库构建管线的基本形态。Patches文档命令在 AIRI 中的真实应用文档给出的补丁三件套pnpm patch pkgversion # 打开可编辑副本并打印路径 pnpm patch-commit path # 写入 patches/*.patch 并记录 pnpm patch-remove pkgversionAIRI 仓库正在使用这套机制pnpm-workspace.yaml 第 38-43 行的patchedDependencies记录了五个生效的补丁与patches/目录下的文件一一对应——patchedDependencies: mineflayer-pathfinder: patches/mineflayer-pathfinder.patch pixi-live2d-display: patches/pixi-live2d-display.patch sponsorkit17.1.0: patches/sponsorkit17.1.0.patch tab-election4.6.2: patches/tab-election4.6.2.patch uiohook-napi1.5.5: patches/uiohook-napi1.5.5.patch可以看到两种写法pkg: path对任意已解析版本生效与pkgversion: path锁定到具体版本如 sponsorkit17.1.0.patch。其中 mineflayer-pathfinder.patch 服务于integrations/minecraft的 Minecraft 玩法集成uiohook-napi1.5.5.patch 服务于桌面端的系统级 hook。修改上游依赖时流程就是文档所述的pnpm patch编辑 →pnpm patch-commit落盘 →patchedDependencies自动更新。本地包链接与 v11 全局包隔离文档说明pnpm link dir # 将路径链接进当前项目的 node_modules仅接受路径 pnpm add -g . # 将当前包的 bin 全局注册v11 破坏性变更pnpm link只接受相对/绝对路径不再支持全局存储解析、--global也不支持裸pnpm link。要用pnpm add -g .让 bin 在系统级可用。全局包v11 isolated installs命令集pnpm add -g typescript prettier # 每个包获得独立隔离安装目录 pnpm add -g eslint,prettier # 逗号 共享同一个安装组 pnpm add -g --allow-buildesbuild esbuild pnpm remove -g pkg pnpm list -g pnpm bin -g # 显示全局 bin 目录$PNPM_HOME/binpnpm install -g无参数不受支持。升级到 v11 后需运行pnpm setup使$PNPM_HOME/bin进入 PATH。AIRI 的 Cloudflare 部署流水线正是 v11 隔离全局安装的实例.github/workflows/deploy-cloudflare-workers-dev-server.yml 中先执行pnpm i -g wrangler4安装 wrangler 4再执行pnpm install --frozen-lockfile安装仓库依赖——两个安装彼此隔离wrangler 的依赖不会污染 workspace 的 lockfile。Runtimes用 pnpm 管理 Node/Deno/Bun文档给出的运行时命令pnpm runtime set node 22 -g # 安装并暴露 node别名rt pnpm runtime set node lts -g pnpm runtime set deno 2 -g pnpm install --no-runtime # 跳过安装 devEngines.runtime 声明的运行时AIRI 的 CI 是该功能的配套实践.github/workflows/ci.yml 第 24-28 行使用pnpm/setupv2并传入runtime: node26.7.0让 pnpm 直接供给 CI 所需的 Node 版本注释解释了钉住 26.7.0 而非跟随 26.8.0 的原因26.8.0 报告预发布版本号导致 sharp 0.29.3 在pnpm install时拒绝安装。开发者本地同样可以用pnpm runtime set node version -g获得一致的运行时环境无需额外的 nvm/fnm。Store 管理与检查/注册表命令Store 管理pnpm store path # 显示存储位置prune 后打印释放大小 pnpm store prune # GC 未被引用的包含全局虚拟存储链接 pnpm store status检查与注册表命令pnpm list # 别名ls pnpm why pkg # 反向依赖树对子树去重 pnpm why --find-byfinder # 从 .pnpmfile.mjs 中取自定义 finder pnpm outdated pnpm audit pnpm peers check # 从 lockfile 报告未满足/缺失的 peer pnpm view pkg [field] # 注册表元数据别名info、show pnpm whoami pnpm rebuild pnpm import # 由 npm/yarn lockfile 生成 pnpm-lock.yaml pnpm dedupeAIRI 根 package.json 第 49 行的up: taze -w -r -I pnpm prune pnpm dedupe是一个值得参考的组合用 taze 批量升级范围后接pnpm prune清理无用依赖、pnpm dedupe折叠重复版本。此外 pnpm-workspace.yaml 第 25-37 行的overrides块如axios: npm:feaxios^0.0.23、多处npm:nolyfill/*替换配合pnpm why使用是定位并治理传递依赖替换的完整链路第 489-523 行的packageExtensions则为vitepress、pixiv/three-vrm-core等包补充了缺失声明的 peerDependencies与pnpm peers check的输出形成对照。发布命令文档给出的发布命令集pnpm pack pnpm publish -r --no-git-checks pnpm version patch|minor|major|2.0.0 # 升版本并 commit tagv11 pnpm version prerelease --preid beta pnpm deprecate pkgrange message pnpm dist-tag add pkgversion tag pnpm unpublish pkgversion # 不推荐优先用 deprecate pnpm sbom --sbom-format cyclonedx # SBOMcyclonedx (1.7) | spdx (2.3) pnpm stage publish ... # 分阶段发布可延后 2FAAIRI 是private: true的仓库publish -r不面向本仓库自身但pnpm version系列命令与根 bump.config.ts、devDependencies 中的bumpp构成版本管理链路仓库通过 release-pkg.yaml 等发布工作流将packages/下的共享库发布到 registry发布产物再由pnpm-lock.yaml锁定的proj-airi/*私有 catalog 版本如 pnpm-workspace.yaml 第 170-176 行消费。维护命令与实用 Flag维护与版本管理命令pnpm self-update [version] # 更新 packageManager 锁定的版本或全局安装 pnpm with current install # 用指定 pnpm 版本执行单条命令 pnpm with 11.0.0 install pnpm approve-builds [--all] # 审查依赖构建脚本写入 allowBuilds实用 Flagpnpm install --ignore-scripts pnpm install --prefer-offline pnpm install --prod # -P跳过 devDependencies pnpm install --no-optional pnpm install --strict-peer-dependencies其中pnpm approve-builds在 AIRI 有直接落点pnpm-workspace.yaml 第 455-488 行的allowBuilds块就是构建脚本审查的产物逐一声明了electron、esbuild、sharp、canvas等需要 postinstall 构建的包true以及明确拒绝的better-sqlite3、prisma/clientfalse。第 483 行还保留了一条注释说明simple-git-hooks被设为false的原因在shellEmulator: true第 12 行下无.git目录时其安装脚本可能失败。这类注释让为什么禁用某构建脚本成为仓库内可追溯的事实。关键要点小结文档末尾的 Key Points 可概括为五条每一条都能在本仓库中找到对应实践pnpm ci clean frozen installCI 自动启用 frozen-lockfile——对应 .github/workflows/ci.yml 各 job 的pnpm install --frozen-lockfiledlx/pnpx是pnx的别名全局安装按包隔离逗号列表可共享安装组——对应 deploy-cloudflare-workers-dev-server.yml 的pnpm i -g wrangler4pnpm link只接受路径暴露全局 bin 请用pnpm add -g .用pnpm runtime set管理 Node/Deno/Bun安装时可用--no-runtime跳过devEngines.runtime声明——对应 CI 中pnpm/setupv2的runtime: node26.7.0v11 新增发布/注册表命令version、view、whoami、deprecate、dist-tag、unpublish、sbom、stage。在 AIRI 仓库中的适用前提本文所有结论基于当前仓库的实际状态pnpm 版本由 package.json 的packageManager: pnpm11.24.0锁定workspace 结构由 pnpm-workspace.yaml 声明含catalogMode: prefer的 catalog 依赖协议与catalogs.vitest命名 catalogCI 运行于 pnpm-lock.yaml 之上。若要复现文中的过滤、patch 或全局安装操作前提是本地 pnpm 版本与该锁定一致可用pnpm self-update对齐并保证pnpm install未在 CI 环境之外改动 lockfile否则--frozen-lockfile会直接报错——这正是该仓库要求本地安装结果可复现的底线。【免费下载链接】airi Self hosted, you-owned Grok Companion, a container of souls of waifu, cyber livings to bring them into our worlds, wishing to achieve Neuro-samas altitude. Capable of realtime voice chat, Minecraft, Factorio playing. Web / macOS / Windows supported.项目地址: https://gitcode.com/GitHub_Trending/ai/airi创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表