Bun 私有包管理：1 个 bunfig.toml 搞定多源注册表

Bun 私有包管理1 个 bunfig.toml 搞定多源注册表【免费下载链接】bunIncredibly fast JavaScript runtime, bundler, test runner, and package manager – all in one项目地址: https://gitcode.com/GitHub_Trending/bu/bun周五下午新同事拉完代码bun install卡了八分钟。原因就一个私有包没走公司源全跑去 npm 官方源撞墙了。其实这事配一个bunfig.toml就能解决——Bun 的注册表配置就住在这个文件里私有源、token、离线模式都写在同一处。Bun 装私有包时替你省掉的三件事安装耗时压到几秒Bun 把装过的包都堆在磁盘上一个全局缓存里再次安装时不重新下载直接硬链接Linux或写时复制macOS进node_modules。装过的私有包在第二台机器上几乎是秒级完成。依赖脚本默认不执行npm 生态的老毛病是恶意代码藏在postinstall里。Bun 默认禁止执行依赖的生命周期脚本只有列进trustedDependencies的包能跑。哪天想审计bun pm untrusted一条命令列出所有没授信的脚本。私有源和公共源各走各的bunfig.toml可以同时写默认源和按作用域scope划分的源。myorg/*走公司仓库其余包照旧走官方源解析阶段自动分流互不打架。从零跑通bunfig.toml 怎么写、怎么验证最小可用配置项目根目录放这么个文件# bunfig.toml [install] registry https://registry.mycompany.com/ token npm_abc123验证配置是否生效跑一遍看解析结果bun install --verbose bun install --dry-run日志里每个依赖都会标来源确认myorg/utils后面挂的是公司源地址就配对了。按需加作用域规则只想让特定作用域走私有源的话加一段[install.scopes] myorg { url https://registry.mycompany.com/, token npm_abc123 }其余包继续走默认源不受影响。三个真实场景怎么接公司有多套包仓库时安全团队一个源、前端组一个源很常见。bunfig.toml里默认源加作用域源可以同时存在sec走 A 仓库、fe走 B 仓库各走各的通道。装完跑bun install --verbose扫一遍日志看每个包的实际来源。发现某个包没按预期走多半是作用域名写错了——myorg和myorg是两个东西。私有包和公共包依赖同一个库的不同版本时解析会打架。用package.json的overrides字段钉死版本全项目统一就不存在冲突了。CI 里不想把 token 写进代码库时token 直接写文件每次提交都是风险。Bun 在配置值里支持$VAR形式引用环境变量[install] registry { url https://registry.mycompany.com/, token $CI_TOKEN }CI 流水线里注入CI_TOKEN环境变量即可文件本身不含任何敏感信息。装包报 401 时先别怀疑网络拿 token 去注册表查一下有效性再核对 URL 和作用域是否对得上——90% 的 401 出在这两处。断网环境也要装包时内网机器连不上外网但包早就装过。两个开关bun install --offline # 只用本地缓存 bun install --prefer-offline # 缓存优先缺失才联网先把内网机器上缓存目录的内容从一台联网机器拷过来再跑--offline。用bun pm cache可以查到缓存位置。上手检查清单项目根目录的bunfig.toml提交进版本库别加进.gitignore跑一次bun install --dry-run确认每个包解析到预期注册表用bun pm untrusted过一遍没授信的依赖脚本CI 里核对CI_TOKEN是否由流水线注入文件里没有明文 token内网机器上跑一次bun install --offline验证缓存完整选项去 bunfig 文档 翻。【免费下载链接】bunIncredibly fast JavaScript runtime, bundler, test runner, and package manager – all in one项目地址: https://gitcode.com/GitHub_Trending/bu/bun创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考