如何给 Bun 配置私有 npm 源：bunfig.toml 注册表实战指南

如何给 Bun 配置私有 npm 源bunfig.toml 注册表实战指南【免费下载链接】bunIncredibly fast JavaScript runtime, bundler, test runner, and package manager – all in one项目地址: https://gitcode.com/GitHub_Trending/bu/bunBun 包管理器的私有注册表配置主要写在项目根目录的bunfig.toml里默认源用install.registry内部作用域包用install.scopes。如果你正在把团队的内部 npm 包迁到 Bun 管理本文从最小可用配置写到认证、验证与排障所有示例都可以直接照抄。场景一个内部包卡住了所有人的 CI假设公司把内部包发布在registry.company.com包名统一带company前缀。项目里执行bun add company/utils时Bun 默认去registry.npmjs.org查找结果只有 404。这类问题本质不是 Bun 的能力缺失而是注册表没有指对地方。Bun 支持同时配置多个注册表公共包走官方源内部包走私有源按作用域自动分流不需要像 npm 那样为每个源单独配一套命令。三步配好最小可用的私有源打开项目根目录的bunfig.toml没有就新建把company作用域指到私有源[install.scopes] company https://registry.company.com/做完这一条company下所有包的解析就会走registry.company.com其余包仍走官方源。运行bun add company/utils验证安装日志里应该能看到请求发往私有源而不是 npmjs.org。作用域名写company或company都可以两种写法等价。官方文档对这个配置项的完整说明见 docs/pm/scopes-registries.mdx。认证怎么配三种写法选一种私有源几乎都要鉴权。bunfig.toml支持三种等价写法区别只在于凭据放在哪[install.scopes] # 1. token 认证最常见 company { url https://registry.company.com/, token npm_abc123 } # 2. 用户名 密码 company { url https://registry.company.com/, username ci-bot, password $NPM_PASS } # 3. 直接把凭据拼进 URL company https://ci-bot:npm_abc123registry.company.com/实际项目里建议用第 1 或第 2 种并且把密钥写成$变量名的形式如$NPM_TOKEN让 Bun 从环境变量取值。这样bunfig.toml可以放心提交进仓库令牌本身不落盘。如果你已经有一份 npm 生态的.npmrcBun 也会读取不用重复配置company:registryhttps://registry.company.com/ //registry.company.com/:_authToken${NPM_TOKEN}需要注意的加载顺序是~/.npmrc→ 项目.npmrc→bunfig.toml→ 环境变量BUN_CONFIG_REGISTRY、NPM_CONFIG_REGISTRY等→ 命令行参数。排在你后面的配置会覆盖前面的排查我明明配了为什么没生效时先确认没有更靠后的配置项把它盖掉了。最快验证方法不真装只看解析结果改完配置先跑一次 dry-run它只做依赖解析、不写node_modulesbun install --dry-run预期看到类似 company/utils1.0.0 (https://registry.company.com/)的输出且包名、版本号、来源 URL 三处都对得上配置就算生效了。这一步能提前暴露大部分 URL 写错、作用域不匹配的问题比等正式安装失败再回滚省事。装不上时按这张表排查现象常见原因处理办法401 / 403令牌过期或作用域与私有源不匹配重新签发令牌确认company与私有源上的包作用域完全一致404包名写错或该作用域没被分流到私有源检查install.scopes的 key用bun install --dry-run看请求实际发往哪个源证书错误内网用了自签 CA在.npmrc里用ca或cafile指定 CA 证书依赖装上了但脚本没跑Bun 默认不执行依赖的生命周期脚本确认该包确需执行脚本后用bun pm trust pkg将其加入package.json的trustedDependencies两个容易忽略的补充缓存命中判断Bun 把下载过的包存在~/.bun/install/cache安装时缓存里有兼容版本就直接用缓存不再请求网络。所以改了配置却像没生效时先确认新版本确实被重新解析了。磁盘不翻倍Linux/Windows 上包是通过硬链接进node_modules的同一版本多个项目共享一份磁盘占用。进阶整源替换与版本统一如果公司要求所有依赖包括公共包都走私有镜像做审计就把作用域配置换成整体替换默认源[install] registry https://registry.company.com/这一条会让lodash这类公共包也从私有源解析适合出口唯一的合规场景。另一个高频需求是统一间接依赖的版本。私有包里可能依赖了不同版本的基础库在package.json里用overrides强制对齐即可{ overrides: { left-pad: 4.1.2 } }常用操作速查目的命令 / 配置给某作用域配私有源bunfig.toml的[install.scopes]整体替换默认注册表bunfig.toml的[install] registry ...验证配置不实际安装bun install --dry-run信任某个包的构建脚本bun pm trust pkg复用现有 npm 配置项目或全局.npmrc配好注册表后团队新同学克隆仓库直接bun install就能装上内部依赖CI 里只需注入令牌环境变量不需要额外装任何插件——私有源这件事在 Bun 里就是几行配置的事。【免费下载链接】bunIncredibly fast JavaScript runtime, bundler, test runner, and package manager – all in one项目地址: https://gitcode.com/GitHub_Trending/bu/bun创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考