思考：如果你编写了一个包 A ，依赖另外一个包 B ，你在编写代码时，包 B 的版本是 2.4.1 ，你是希望使用你包的人一定要安装包 B ，并且是 2.4.1 版本，还是希望他可以安装更高的版本，如果你希望它安装更高的版本，高的什么程度呢？

回顾 版本号规则

  1. 版本规范：主版本号.次版本号.补丁版本号

    • 主版本号：仅当程序发生了重大变化时才会增长，如新增了重要功能、新增了大量的 API、技术架构发生了重大变化；
    • 次版本号：仅当程序发生了一些小变化时才会增长，如新增了一些小功能、新增了一些辅助型的 API；
    • 补丁版本号：仅当解决了一些 bug 或 进行了一些局部优化时更新，如修复了某个函数的 bug、提升了某个函数的运行效率；

  2. 有的时候：

    • 我们希望：安装依赖包的时候，次版本号和补丁版本号是可以有提升的，但是主版本号不能变化；
    • 我们又希望：安装依赖包的时候，只有补丁版本号可以提升，其他都不能提升；
    • 甚至我们希望依赖包保持固定的版本，尽管这比较少见；

  3. 这样一来，就需要在配置文件中描述清楚具体的依赖规则，而不是直接写上版本号那么简单；这种规则的描述，即 语义版本；

  4. 语义版本的书写规则非常丰富，下面列出了一些常见的书写方式

    符号 描述 示例 示例描述
    > 大于某个版本 >1.2.1 大于 1.2.1 版本
    >= 大于等于某个版本 >=1.2.1 大于等于 1.2.1 版本
    < 小于某个版本 <1.2.1 小于 1.2.1 版本
    <= 小于等于某个版本 <=1.2.1 小于等于 1.2.1 版本
    - 介于两个版本之间 1.2.1 - 1.4.5 介于 1.2.1 和 1.4.5 之间
    x 不固定的版本号 1.3.x 只要保证主版本号是 1，次版本号是 3 即可
    ~ 补丁版本号可增 ~1.3.4 保证主版本号是 1，次版本号是 3，补丁版本号大于等于 4
    ^ 次版本和补丁版本可增 ^1.3.4 保证主版本号是 1，次版本号可以大于等于 3，补丁版本号可以大于等于 4
    * 最新版本 * 始终安装最新版本

避免还原的差异

  1. 版本依赖控制始终是一个两难的问题：

    • 如果允许版本增加，可以让依赖包的 bug 得以修复（补丁版本号），可以带来一些意外的惊喜（次版本号），但同样可能带来不确定的风险（新的 bug）；
    • 如果不允许版本增加，可以获得最好的稳定性，但失去了依赖包自我优化的能力；

  2. 而有的时候情况更加复杂，如果依赖包升级后，依赖也发生了变化，会有更多不确定的情况出现；基于此，npm 在安装包的时候，会自动生成一个 package-lock.json 文件，该文件记录了安装包时的确切依赖关系；

  3. 当移植工程时，如果移植了 package-lock.json 文件，恢复安装时，会按照 package-lock.json 文件中的确切依赖进行安装，最大限度的避免了差异；

npm 的差异版本处理

  1. 如果两个包依赖同一个包的不同版本，如下图

  2. 面对这种情况，在 node_modules 目录中，不会使用扁平的目录结构，而会形成嵌套的目录，如下图：

打赏作者
您的打赏是我前进的动力
微信
支付宝
评论

中午好👏🏻，我是 ✍🏻   疯狂 codding 中...

粽子

这有关于前端开发的技术文档和你分享。

相信你可以在这里找到对你有用的知识和教程。

了解更多

目录

  1. 1. 回顾 版本号规则
  2. 2. 避免还原的差异
  3. 3. npm 的差异版本处理