npm-publish by b-open-io/prompts
npx skills add https://github.com/b-open-io/prompts --skill npm-publish使用 bun 发布 npm 包,包含正确的版本管理、更新日志管理和 git 工作流。
首先,检查用户是否已登录 npm:
npm whoami
如果该命令返回用户名,则继续。如果报错显示“未登录”,请停止并告知用户:
“您需要先登录 npm。请在终端中运行
npm login并完成身份验证,完成后告诉我。”
在 npm whoami 成功之前,不要继续任何发布步骤。 用户必须自行处理 npm 登录,因为这需要交互式身份验证。
确定需要发布的内容:
# 检查最后发布的版本
npm view <package-name> version
# 检查本地 package.json 版本
cat package.json | grep '"version"'
# 检查自上次发布以来的提交
git log --oneline $(git describe --tags --abbrev=0 2>/dev/null || echo HEAD~10)..HEAD
如果不存在标签,请检查 git 日志中的发布提交,以确定上次发布的状态。
对于处于快速/早期开发阶段(0.x.x)的项目,始终提升补丁版本号:
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
0.0.1 → 0.0.2 → 0.0.3 ...
除非明确要求,否则避免提升主版本号或次版本号。早期项目受益于频繁的小版本发布。
编辑 package.json 以更新版本字段。
检查是否存在更新日志。如果存在,请按照现有格式为新版本添加条目。典型结构如下:
## [X.X.X] - YYYY-MM-DD
### 新增
- 新功能
### 变更
- 现有功能的更改
### 修复
- 错误修复
将自上次发布以来的提交总结到适当的类别中。
运行项目的构建命令以确保一切编译正常:
bun run build
关键:在发布到 npm 之前,始终先推送到 git。
git add package.json CHANGELOG.md
git commit -m "Release vX.X.X"
git push origin <branch>
这确保了发布的代码与仓库中的代码匹配。在推送之前发布会导致版本不匹配,需要额外的发布来修复。
在尝试发布之前,向用户请求他们的 npm OTP(一次性密码)代码。这是 npm 双因素认证的标准做法:
“请提供您的 npm OTP 代码以进行发布。”
等待用户提供 6 位代码后再继续。
使用 bun publish 并附带 OTP:
bun publish --access public --otp <code>
对于作用域包(@org/package),除非发布到私有注册表,否则需要 --access public。
发布后,验证新版本是否已上线:
npm view <package-name> version
注意: bun/npm 注册表可能需要最多 5 分钟才能反映新版本。不要尝试通过直接使用 npm 或重新发布来规避此延迟。只需等待,并在需要时再次验证。
如果该版本已存在于 npm 上,请提升到下一个补丁版本并重复工作流程。
OTP 代码具有时效性(通常为 30 秒)。如果由于 OTP 过期导致发布失败,请向用户请求新的代码。
成功发布后,npm view 可能仍会在几分钟内显示旧版本。这是正常行为——不要重新发布或尝试变通方法。
每周安装量
63
仓库
GitHub 星标数
8
首次出现
2026年1月22日
安全审计
安装于
opencode56
gemini-cli54
claude-code52
codex52
github-copilot50
cursor46
Publish npm packages using bun with proper versioning, changelog management, and git workflow.
First, check if the user is logged into npm:
npm whoami
If this returns a username, proceed. If it errors with "not logged in", stop and instruct the user:
"You need to log into npm first. Please run
npm loginin your terminal and complete authentication, then let me know when you're ready."
Do not proceed with any publish steps untilnpm whoami succeeds. The user must handle npm login themselves as it requires interactive authentication.
Determine what needs to be released:
# Check last published version
npm view <package-name> version
# Check local package.json version
cat package.json | grep '"version"'
# Check commits since last release
git log --oneline $(git describe --tags --abbrev=0 2>/dev/null || echo HEAD~10)..HEAD
If no tags exist, check git log for release commits to identify the last published state.
For projects in rapid/early development (0.x.x), always bump the patch version:
0.0.1 → 0.0.2 → 0.0.3 ...
Avoid major or minor bumps unless explicitly requested. Early-stage projects benefit from frequent small releases.
Edit package.json to update the version field.
Check if a changelog exists. If so, add an entry for the new version following the existing format. Typical structure:
## [X.X.X] - YYYY-MM-DD
### Added
- New features
### Changed
- Changes to existing functionality
### Fixed
- Bug fixes
Summarize the commits since the last release into appropriate categories.
Run the project's build command to ensure everything compiles:
bun run build
Critical: Always push to git before publishing to npm.
git add package.json CHANGELOG.md
git commit -m "Release vX.X.X"
git push origin <branch>
This ensures the published code matches what's in the repository. Publishing before pushing creates version mismatches that require additional releases to fix.
Before attempting to publish, ask the user for their npm OTP (One-Time Password) code. This is standard practice for npm 2FA:
"Please provide your npm OTP code for publishing."
Wait for the user to provide the 6-digit code before proceeding.
Use bun publish with the OTP:
bun publish --access public --otp <code>
For scoped packages (@org/package), --access public is required unless publishing to a private registry.
After publishing, verify the new version is live:
npm view <package-name> version
Note: The bun/npm registry may take up to 5 minutes to reflect the new version. Do not attempt to work around this delay by using npm directly or re-publishing. Simply wait and verify again if needed.
If the version already exists on npm, bump to the next patch version and repeat the workflow.
OTP codes are time-sensitive (usually 30 seconds). If publishing fails due to expired OTP, request a fresh code from the user.
After successful publish, npm view may still show the old version for several minutes. This is normal behavior—do not re-publish or attempt workarounds.
Weekly Installs
63
Repository
GitHub Stars
8
First Seen
Jan 22, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykFail
Installed on
opencode56
gemini-cli54
claude-code52
codex52
github-copilot50
cursor46
GitHub Actions 官方文档查询助手 - 精准解答 CI/CD 工作流问题
45,200 周安装