【声明】本博客所有内容均为个人业余时间创作所述技术案例均来自公开开源项目如GithubApache基金会不涉及任何企业机密或未公开技术如有侵权请联系删除背景上篇 blog【Agent】【OpenCode】项目配置package.json 和 bun.lock提到了package.json和bun.lock的区别其中package.json定义了项目允许安装的版本范围以提供灵活性而bun.lock则锁定了实际安装的精确版本和依赖树确保团队环境的一致性在devDependencies和dependencies中依赖的软件包后面会跟着一串数字当后面是纯数字的精确版本号时就代表只允许安装这个绝对精确的版本没有任何范围可言但在真实的开发中写死一个绝对的版本号会降低灵活性所以开发者通常会在版本号前面加上特定的符号来约束版本范围其中插入符^允许更新次版本和补丁版本而波浪号~仅允许更新补丁版本代表希望获得最大程度的稳定性接着分析了 bun.lock 文件package.json负责声明版本范围而 Lock 文件则会实时锁定当前实际安装的精确版本号只要团队里大家都基于同一个 Lock 文件安装无论package.json里规定的范围有多宽最终每个人电脑上运行的都是完全一模一样的环境下面继续分析OpenCode上篇 blog 分析了package.json和bun.lock各自的作用一个负责范围另一个负责控制精确的版本号这里有人可能会有疑问既然 Lock 文件都已经锁死了依赖包的版本号那么在package.json里声明范围还有什么用这里打个比方package.json里的版本范围就像是公司的招聘要求而 Lock 文件则是最终发下去的正式 Offer如果只有 Offer 没有招聘要求这家公司就彻底失去了招新人和更新换代的能力具体来说package.json中的版本范围控制有以下三个重要作用安全升级通行证Lock 文件确实把当前的环境锁住了但如果用户需要获取新的 Bug 修复或新功能时如果有^或~开发者只需要执行一次npm update或者bun update包管理器就会在package.json允许的范围内自动拉取最新的兼容版本并同步更新 Lock 文件注意这里的 Lock 文件是本地的不会影响库上其他人的环境如果没有范围全写死一旦某个底层库爆出了高危漏洞开发者就必须手动去改package.json里的版本号然后再重新安装这就会增加维护成本此外package.json的版本范围控制还是团队协作的沟通契约package.json是面向开发者的向团队传达了明确的意图比如当同事看到express: ^4.18.2时就能立刻明白作者允许在这个项目里使用express 4.x的任何小版本如果他发现了一个极好的4.19.0版本的性能优化就知道可以直接用但如果想升级到5.0.0他就会知道这需要经过严格的代码重构和测试如果没有这个范围别人就不知道这个项目的底线在哪里最后版本范围也是解决依赖冲的边界线现代项目的依赖树很复杂假设 A 库要求lodash: ^4.17.0而 B 库要求lodash: ~4.17.20包管理器在解析依赖树的时候必须知道每个包的可接受底线在哪里才能算出一个大家都能接受的交集版本如果大家都只给一个绝对精确的版本号稍微有一点错开整个依赖树就会因为无法匹配而直接崩溃报错OK之前 blog 提到了 SemVerSemVer 的全称是 Semantic Versioning语义化版本控制这是现代软件工程中最重要的版本命名规范之一其核心目的是通过一套标准化的版本号格式让开发者仅看一眼版本号就能准确判断出此次更新包含了什么性质的变更以及是否会导致现有代码报错兼容性SemVer 标准的语义化版本号由三段数字组成格式为【MAJOR.MINOR.PATCH】主版本.次版本号.修订号每段数字的递增都有着明确含义MARJOR主版本号不兼容的重大变更当对公共 API 进行了任何破坏性修改导致旧版本的依赖方必须修改代码才能使用新版本时主版本号加 1且次版本号和修订号归零比如删除了某个公开的方法改变了方法的参数结构或者重构导致旧接口无法正常工作等比如从1.5.0升级到2.0.0MINOR次版本号向下兼容的功能新增当添加了新功能但这些新功能不会破坏现有代码的运行逻辑时次版本号加 1且修订号归零比如增加了一个全新的方法新增了可选参数等比如从1.4.2升级到1.5.0PATCH修订号/补丁号向下兼容的问题修复当仅仅修复了 Bug 或进行了内部性能优化而没有改变任何对外行为时修订号加 1比如修复了登录时的崩溃问题优化了底层算法速度等比如从1.4.2升级到1.4.3OK本篇先到这里如有疑问欢迎评论区留言讨论祝各位功力大涨技术更上一层楼更多内容见下篇 blog【Agent】【OpenCode】项目配置SemVer补充
115、【Agent】【OpenCode】项目配置（SemVer）
【声明】本博客所有内容均为个人业余时间创作所述技术案例均来自公开开源项目如GithubApache基金会不涉及任何企业机密或未公开技术如有侵权请联系删除背景上篇 blog【Agent】【OpenCode】项目配置package.json 和 bun.lock提到了package.json和bun.lock的区别其中package.json定义了项目允许安装的版本范围以提供灵活性而bun.lock则锁定了实际安装的精确版本和依赖树确保团队环境的一致性在devDependencies和dependencies中依赖的软件包后面会跟着一串数字当后面是纯数字的精确版本号时就代表只允许安装这个绝对精确的版本没有任何范围可言但在真实的开发中写死一个绝对的版本号会降低灵活性所以开发者通常会在版本号前面加上特定的符号来约束版本范围其中插入符^允许更新次版本和补丁版本而波浪号~仅允许更新补丁版本代表希望获得最大程度的稳定性接着分析了 bun.lock 文件package.json负责声明版本范围而 Lock 文件则会实时锁定当前实际安装的精确版本号只要团队里大家都基于同一个 Lock 文件安装无论package.json里规定的范围有多宽最终每个人电脑上运行的都是完全一模一样的环境下面继续分析OpenCode上篇 blog 分析了package.json和bun.lock各自的作用一个负责范围另一个负责控制精确的版本号这里有人可能会有疑问既然 Lock 文件都已经锁死了依赖包的版本号那么在package.json里声明范围还有什么用这里打个比方package.json里的版本范围就像是公司的招聘要求而 Lock 文件则是最终发下去的正式 Offer如果只有 Offer 没有招聘要求这家公司就彻底失去了招新人和更新换代的能力具体来说package.json中的版本范围控制有以下三个重要作用安全升级通行证Lock 文件确实把当前的环境锁住了但如果用户需要获取新的 Bug 修复或新功能时如果有^或~开发者只需要执行一次npm update或者bun update包管理器就会在package.json允许的范围内自动拉取最新的兼容版本并同步更新 Lock 文件注意这里的 Lock 文件是本地的不会影响库上其他人的环境如果没有范围全写死一旦某个底层库爆出了高危漏洞开发者就必须手动去改package.json里的版本号然后再重新安装这就会增加维护成本此外package.json的版本范围控制还是团队协作的沟通契约package.json是面向开发者的向团队传达了明确的意图比如当同事看到express: ^4.18.2时就能立刻明白作者允许在这个项目里使用express 4.x的任何小版本如果他发现了一个极好的4.19.0版本的性能优化就知道可以直接用但如果想升级到5.0.0他就会知道这需要经过严格的代码重构和测试如果没有这个范围别人就不知道这个项目的底线在哪里最后版本范围也是解决依赖冲的边界线现代项目的依赖树很复杂假设 A 库要求lodash: ^4.17.0而 B 库要求lodash: ~4.17.20包管理器在解析依赖树的时候必须知道每个包的可接受底线在哪里才能算出一个大家都能接受的交集版本如果大家都只给一个绝对精确的版本号稍微有一点错开整个依赖树就会因为无法匹配而直接崩溃报错OK之前 blog 提到了 SemVerSemVer 的全称是 Semantic Versioning语义化版本控制这是现代软件工程中最重要的版本命名规范之一其核心目的是通过一套标准化的版本号格式让开发者仅看一眼版本号就能准确判断出此次更新包含了什么性质的变更以及是否会导致现有代码报错兼容性SemVer 标准的语义化版本号由三段数字组成格式为【MAJOR.MINOR.PATCH】主版本.次版本号.修订号每段数字的递增都有着明确含义MARJOR主版本号不兼容的重大变更当对公共 API 进行了任何破坏性修改导致旧版本的依赖方必须修改代码才能使用新版本时主版本号加 1且次版本号和修订号归零比如删除了某个公开的方法改变了方法的参数结构或者重构导致旧接口无法正常工作等比如从1.5.0升级到2.0.0MINOR次版本号向下兼容的功能新增当添加了新功能但这些新功能不会破坏现有代码的运行逻辑时次版本号加 1且修订号归零比如增加了一个全新的方法新增了可选参数等比如从1.4.2升级到1.5.0PATCH修订号/补丁号向下兼容的问题修复当仅仅修复了 Bug 或进行了内部性能优化而没有改变任何对外行为时修订号加 1比如修复了登录时的崩溃问题优化了底层算法速度等比如从1.4.2升级到1.4.3OK本篇先到这里如有疑问欢迎评论区留言讨论祝各位功力大涨技术更上一层楼更多内容见下篇 blog【Agent】【OpenCode】项目配置SemVer补充
