Node.js中package.json中库的版本号

更新日期: 2019-03-02阅读: 2.3k标签: package

~和^的区别

最近总是碰到一些问题, 在本地好好的, 在线上就出现了问题, 本地也一直复现不了, 后来把node_modules目录删除了之后, 重新安装, 就在本地复现了这个问题,可以看了git history, 并没有人修改package.json中的版本号,于是认真的了解了一下package.json中库的版本号;

~和^的区别

    "babel-loader": "^7.1.1",
    "body-parser": "~1.15.2"

npm install --save xxx, 会优先考虑使用 ^而不是~

以版本号x.y.z为例
x:主版本号, 当你做了不兼容的api修改
y:次版本号, 当你做了向下兼容的功能性问题
z:修订号, 当你做了向下兼容的问题修复

~x.y.z, 会更新到y最新的版本, 例如 body-parser: ~1.15.2, 这个库会去匹配到1.15.z的最新版本, 如果出现了1.16.0, 则不会自动升级
^x.y.z, 会更新到x的最新版本, 例如 babel-loader: ^7.1.1, 这个库会去匹配7.y.z的最新版本, 如果出现了8.1.1, 则不会自动升级

可以参考npm官方给出的解释
^1.2.3 := >=1.2.3 <2.0.0
^0.2.3 := >=0.2.3 <0.3.0
^0.0.3 := >=0.0.3 <0.0.4

大多数情况下遵循这种版本号规则的依赖包都没问题, 但是npm是开源的世界, 并不是所有的都严格遵循这种规则, 所以会出现上述的问题;


为什么需要package锁

有如下几个可能原因, 在某些情况下, package.json是无法保证每个人自己电脑上执行的 npm install 后安装的依赖版本都是一样的
1.如果package.json中记录的依赖包的版本是一个版本范围, 一旦执行npm i 会导致这个包更新到最新版本
2.就算你依赖了一个固定版本的包(如A 1.1.1), 但你依赖的包A可能依赖其他的包B,而A在声明依赖时可能也使用了semser命名, 如 ^1.2.3, 如果包B release 了新版, 也会导致包B会安装到更新版本
3.不同人使用的npm程序的版本不同

如果依赖包的版本不一致, 会导致开发环境和生产环境产品不一致的行为; 或者导致不同团队成员之前也产品环境差异


如何解决包版本不一致的情况

1.npm 使用package-lock.json文件来解决这个问题

执行npm install会自动生成package.json文件, 只要执行普通的安装, 更新等可能会修改 package.json的npm命令, 都会自动同步修改package-lock.json文件

npm install xxx
npm rm xxx
npm update xxx

2.npm 还支持npm-shrinkwrap.json, 和package-lock.json功能完全一样

执行 npm shrinkwrap来生成npm-shrinkwrap.json
此命令将根据 package-lock.json 文件创建一个新的或覆盖已有的 npm-shrinkwrap.json 文件。 此命令创建和更新的文件将优先于任何其他现有或将有的 package-lock.json 文件。

3.使用yarn

使用yarn主要有一下优点

  • 快速: 会缓存它下载的每个包,无需重复下载;能并行化操作以最大资源利用率
  • 可靠:使用格式详尽而又简洁的 lockfile文件 和确定性算法来安装依赖,能够保证在一个系统上的运行的安装过程也会以同样的方式运行在其他系统上。
  • 安全: 安装包被执行前校验其完整性
yarn速度比npm快一些, yarn的锁文件是yarn.lock, 能解决包版本不一致的情况

链接: https://fly63.com/article/detial/2674

package.json的所有配置项及其用法,你都熟悉么

在前端开发中,npm已经是必不可少的工具了。使用npm,不可避免的就要和package.json打交道。平时package.json用得挺多,但是没有认真看过官方文档。本文结合npm官方文档以及自己平时使用过程中的感悟

package.json 和 package-lock.json 文件说明

在 Node.js 中,模块是一个库或框架,也是一个 Node.js 项目。Node.js 项目遵循模块化的架构,当我们创建了一个 Node.js 项目,意味着创建了一个模块,这个模块的描述文件,被称为 package.json。

package.json中你还不清楚的browser,module,main 字段优先级

前端开发中使用到 npm 包那可算是家常便饭,而使用到 npm 包总免不了接触到 package.json 包配置文件。那么这里就有一个问题,当我们在不同环境下 import 一个 npm 包时,到底加载的是 npm 包的哪个文件?

逐行理解create-react-app中的package.json

下面是我的react项目初始化之后的package.json文件,除了个别自己新增依赖以外,基本是create-react-app生成的默认配置,下面是对package.json中每一行(除jest之外)的解释:

Package.json详解

前端需要学习的东西真的挺多的,之前主要从事的是MVC框架,操作DOM,使用JQUERY比较多,不知到什么时候,发现现在前端MVVM是主流,不得不把之前的大部分东西丢掉,作为前端婴儿不断前行。

package.json 与 package-lock.json 的区别

根据官方文档,这个package-lock.json 是在 `npm install`时候生成一份文件,用以记录当前状态下实际安装的各个npm package的具体来源和版本号。它有什么用呢?因为npm是一个用于管理package之间依赖关系的管理器

什么是package.json文件?了解package.json常见属性

Node 项目在项目根目录中名为 package.json 的文件中跟踪依赖关系和元数据。这是你项目的核心。它包含名称、描述和版本之类的信息,以及运行、开发以及有选择地将项目发布到 NPM 所需的信息。

关于前端大管家 Package.Json,你知道多少?

在每个前端项目中,都有package.json文件,它是项目的配置文件,常见的配置有配置项目启动、打包命令,声明依赖包等。package.json文件是一个JSON对象

深入浅出 package.json,目测大多数人不了解它

package.json中也存在很多三方属性,比如tsc中使用的types、构建工具中使用的sideEffects,git中使用的husky,eslint使用的eslintIgnore,这些扩展的配置,针对特定的开发工具是有意义的这里不一一举例。

再也不用手动改package.json的版本号

本文的起因是有在代码仓库发包后,同事问我“为什么package.json 里的版本还是原来的,有没有更新?”,这个时候我意识到,我们完全没有必要在每次发布的时候还特意去关注这个仓库的版本号

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!