现代的前端开发、Node.js 后端开发中 NPM 包管理是最基础也是最关键的一部分,本文将从一个问题开始,阐述 NPM 版本控制的工作原理,我相信这是每一个使用了 NPM 的开发人员都应该熟悉的知识。
事情的经过是前一天测试还一切正常,第二天部署时却提示 yarn 安装依赖失败,下面是本地复现的结果,如下图所示:
yarn 安装失败
一个明显的提示是 bson@5.0.0 这个依赖不再支持 Node.js 14.20.1 以下版本,但是项目的 dependencies 中也没有指定这个包啊,了解 MongoDB 的同学应该知道 bson 是 Mongo 实现的一个类 JSON 的二进制存储格式。
为了一探究竟,执行 yarn --ignore-engines 先忽略这个引擎检测,看下 yarn.lock 文件中 bson 的依赖关系。
mongoose@^5.3.0 是项目中的依赖,实际安装后使用的版本为 5.13.5,之后又依赖了 @types/mongodb,问题来了,这里竟然使用了 @types/bson: * 要知道在 NPM 的版本号规则里 * 号是不会锁定版本的,每次都会升级为最新版本,也就是最后的 bson: 5.0.0。
查了下 bson 这个库的 CHANGELOG 发现其在 2023-01-31 号发布了 5.0.0,要求 Node.js 版本必须大于 14.20.1,上面报错显然当前版本不满足。
库的版本升级很正常,了解 NPM 版本号规则的同学应该知道 “bson: 5.0.0 ” 这是一个大版本,会存在不向前兼容的情况,这里的问题在于 @types/mongodb 直接使用了 @types/bson: *,每次安装都会升级到最新,是有点不讲 “码德”,这里是个坑,NPM 上查了 @types/mongodb 这个包,发现已经被废弃了,如下图所示:
mongoose 这个包的影响版本为:mongoose 5.11 ~ 5.13.15。
这里先抛出一个问题:“为什么安装时使用的 mongoose@^5.3.0 安装成功后却变成了 5.13.15”?
在发布 NPM 模块新版本时,建议遵循 “语义版本控制” 考虑使用这样的版本号x.y.z 控制,如下所示:
版本号规则:
在发布 NPM 包时建议从 1.0.0 开始,例如:
语义化版本号的几种表示方法:
了解了语义化版本号规则后,应该要知道上面提出的一个问题:“为什么安装时使用的 mongoose@^5.3.0 安装成功后却变成了 5.13.15”,因为版本号前加 ^ 符号,它表示的是第一位保持不变、最后两位升级到最新。
考虑一个问题,项目第一次添加一个模块的依赖是 ^1.2.3,过了两周另一个同事需要修这个项目,此时依赖已经更新到 1.3.0 他在重新安装后就会得到最新的版本,这会带来一个问题,每个人得到依赖版本不一致,该如何确保团队成员的依赖版本都是一致呢?
解决依赖版本不一致的问题一种方法是 “固定依赖版本”,但在实际做法中这种很少见,大多数时候没有意识到一个问题 “安全修复”,通过版本号前加 ^ 或 ~ 符号我们可以得到补丁版本错误修复、向前兼容的小版本新功能。
解决依赖版本不一致的另一种方法是通过 lock 文件(NPM 中的 package-lock.json 或 yarn 中的 yarn.lock )来解决同一个项目团队成员之间依赖版本不一致的问题,在使用 npm 或 yarn 安装之前会先检查 lock 文件上的版本,并来安装它们,有必要将 lock 文件推送至 git 仓库。
如果需要将依赖项更新到指定范围的最新版本,只需要执行 npm update 命令,该命令会遵循语义化版本控制对依赖进行升级,同时也会更新 lock 文件。
网站标题:一次 yarn 安装依赖失败,让我重新认识了 NPM 版本号规则
链接分享:http://www.shufengxianlan.com/qtweb/news11/350611.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联