技能介绍

解决什么问题

在 npm 发布流程里，一旦代码合入主干再发现问题，回滚和重新发版都很重。真正有效的验证往往要落在“使用者能安装这个包”这一步，而不是只看 CI 测试通过。这个技能面向一种典型场景：某个 PR 改了库的公开 API 或打包配置，评审者想直接尝试安装这个 PR 构建出来的包，尽早发现类型缺失、入口文件不对、依赖版本冲突等问题，而不是等到维护者切出 tag、发布到 npm 之后。

它如何工作

核心思路是把 可安装的包预览 作为 PR 的交付物，而不是只产出日志或截图。技能围绕 pkg.pr.new 组织流程：先在仓库安装对应的 GitHub App，让 Actions 能够代表 PR 执行发布；再把 pkg-pr-new 写入仓库依赖，保证锁文件中的依赖是可复现的；最后在 workflow 中调用 pkg-pr-new publish，按工作区路径把构建产物发布成与 PR 关联的预览包。

典型步骤包括：确认仓库启用了 Actions 并配置了 Node.js 20；将发布动作限定在需要验证的包路径上，例如 ./packages/A、./packages/B 或 ./packages/*；在 CI 中触发并生成预览构建；评审者从锁文件安装该预览版本，在实际项目里跑通引入、类型检查、运行示例等验证动作。这样反馈会直接指向“包能不能装、能不能用”，而不是停留在评审评论区的主观判断。

适用边界与注意点

这个方案更适合 包可以被 CI 构建 的仓库：存在清晰的构建步骤、产物路径和入口定义，能够从 PR 的工作区稳定生成可安装结果。它解决的是发布前验证，不是替代常规的版本管理、语义化版本策略或正式发版流程。

需要注意两点：一是 GitHub App 权限与 Actions 运行环境要提前确认，权限不足会导致预览包无法生成或无法关联到对应 PR；二是发布命令应尽量从锁文件驱动，例如在 monorepo 中显式指定包路径，避免把无关包暴露给评审者。对于还处于原型期、没有稳定构建入口的包，先补齐构建与产物约定，再引入 PR 预览安装会更有效。