package.json版本与lock机制讲解

我们在搭建项目的时候，通过 npm 安装的依赖模块时，package.json文件中依赖的版本号前面会带符号 ^，有时候我们看别人的项目时也可能会看版本前带符号 ~ ，或者什么也不带，其中会有什么区别呢？

而且当你的 npm 版本升级到 5.X.X 版本以上的时候，对应目录下还是自动生成一个 package-lock.json 文件（cnpm不支持package-lock.json），这个文件的作用又是什么呢？在接下来的讲解中，我们会逐一解答。

package.json 版本

"dependencies": {
    "echarts": "^5.3.0"
    "echarts": "~5.3.0",
    "echarts": "5.3.0",
  },

如上，三种方式的区分在于，项目通过 npm install 重新下载依赖包时，对于所下载的版本号的区别：

• ‘^5.3.0’ 表示安装5.x.x的最新版本，安装时不改变大版本号。
• ‘~5.3.0’ 表示安装5.3.x的最新版本，安装时不改变大版本号和次要版本号。
• ‘5.3.0’ 表示安装指定的版本号，也就是安装5.3.0版本。

我们可以通过

npm view echarts versions

来查看到目前我们所能获取到的所有远程echarts的版本

  '4.9.0',           '5.0.0-alpha.1',   '5.0.0-alpha.2',   '5.0.0-beta.1',
  '5.0.0-beta.2',    '5.0.0-rc.1',      '5.0.0',           '5.0.1',
  '5.0.2',           '5.1.0',           '5.1.1',           '5.1.2',
  '5.2.0',           '5.2.1',           '5.2.2',           '5.3.0-rc.1',
  '5.3.0',           '5.3.1-rc.1',      '5.3.1',           '5.3.2-rc.1',
  '5.3.2',           '5.3.3-rc.1',      '5.3.3',           '5.4.0-rc.1',
  '5.4.0',           '5.4.1-rc.1',      '5.4.1',           '5.4.2-rc.1',
  '5.4.2',           '5.4.3-rc.1',      '5.4.3'

也可以通过

npm view echarts version

查看远程echarts的最新稳定版本,目前最新的是5.4.3

以这个为例，上述的三种写法，最终install的版本号分别为：

• ‘^5.3.0’ 安装5.4.3
• ‘~5.3.0’ 安装5.3.3
• ‘5.3.0’ 安装5.3.0

所以，上面三种写法除了直接是5.3.0这种，其他两种都有可能实际安装的版本号与 package.json 文件中的版本号不一致。

我们可以通过在项目中执行：

npm ls echarts

来查看目前项目中安装的echarts的具体版本号。

也可以加上-g查看全局安装的echarts

npm ls echarts -g

正常情况下，依赖包的版本都是向下兼容的，所以通过^5.3.0 和~5.3.0这两种方式也很少报错。npm 默认的带^ ，你可以通过 npm config set save-prefix='~'将 ~ 设置为默认符号。

package-lock.json 的作用

package-lock.json 的作用就是为了避免上述的 package.json 中的版本号与实际安装的不一致的问题。package-lock.json 在 npm 版本为 5 以上时，会自动生成。

官方的解释是：

package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json. It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates.

通俗的说就是：package-lock.json里会维护一个依赖管理树，里面记录着每个依赖的确定版本, 获取地址和哈希值等信息，这样就保证了每次安装下载的依赖版本都是一样的。

如下是 package-lock.json 中的 echarts 的相关信息：

"echarts": {
  "version": "5.4.3",
  "resolved": "https://registry.npmjs.org/echarts/-/echarts-5.4.3.tgz",
  "integrity": "sha512-mYKxLxhzy6zyTi/FaEbJMOZU1ULGEQHaeIeuMR5L+JnJTpz+YR03mnnpBhbR4+UYJAgiXgpyTVLffPAjOTLkZA==",
  "requires": {
    "tslib": "2.3.0",
    "zrender": "5.4.4"
  }
},

如果想要更新dependencies中依赖包的版本号，需要使用 npm i packageName@x.x.x -S 这种方式来进行版本更新，这样 package-lock.json 文件才可以中也会对应做更新，如npm i echarts@5.4.3 -S。

大致意思是，如果改了package.json依赖包的版本号，且package.json和lock文件版本号不同，那么执行npm i时npm会根据package中的版本号以及语义含义去下载最新的包，并更新至lock。如果两者版本号一致，那么执行npm i 都会根据lock下载，不会理会依赖包是否有新版本。

package-lock.json 需要写进 .gitignore 吗？

package-lock.json 不应写进 .gitignore 。这点无论你是否使用 lock 都是一样的。

具体来说：

• 如果你使用 lock 机制，则应该将 package-lock.json 提交到 repo 中。比如 Vue 采取了该策略。

• 如果你不使用 lock 机制，则应该加入 .npmrc 文件，内容为 package-lock=false ，并提交到 repo 中。比如 ESLint 采取了该策略。

• 例外是，如果你使用 yarn 并且不打算使用 npm，则可以把 package-lock.json 列入 .gitignore （比如 Babel）；反之如果你使用 npm 并且不打算使用 yarn，则可以把 yarn.lock 列入 .gitignore （比如 TypeScript）。

如果你不按照上述方式做，请确定你清楚自己在干什么。有一些不使用 lock 机制的库，已经使用了 .npmrc ，但也把 package-lock.json 列入了 .gitignore ，这是没有必要的。

大多数情况下，Lock机制无比重要。为什么？为了保证多人开发的统一性。

什么是统一性？就是无论何时来了一个新人、换了个新电脑，我们npm i的包都是一致的。随着项目越来越大，依赖越来越多，很难保证每一个npm包的最新版本都是适合的、有用的。Lock机制可以最大化解决此类冲突。在多人协作时同步开发环境。至于什么时候用新的包，到时候再同步lock文件就是。