npm-shrinkwrap.json 和 package-lock.json 有什么区别?

What is the difference between npm-shrinkwrap.json and package-lock.json?

对于 release of npm@5,它现在将写入 package-lock.json,除非 npm-shrinkwrap.json 已经存在。

我通过以下方式全局安装了 npm@5:

npm install npm@5 -g

现在,如果 npm-shrinkwrap.json 在以下期间被发现:

npm install

将打印警告:

npm WARN read-shrinkwrap This version of npm
is compatible with lockfileVersion@1,
but npm-shrinkwrap.json was generated for lockfileVersion@0.
I'll try to do my best with it!

所以我的收获是我应该用 package-lock.json 替换收缩包装。

可是为什么要有新的格式呢? package-lock.json 能做什么而 npm-shrinkwrap.json 不能?

我认为这个想法是让 --save 和 shrinkwrap 默认发生,但避免在不需要的地方发生 shrinkwrap 的任何潜在问题。所以,他们只是给它一个新的文件名以避免任何冲突。来自 npm 的人在这里更彻底地解释了它:

https://www.reddit.com/r/javascript/comments/6dgnnq/npm_v500_released_save_by_default_lockfile_better/di3mjuk/

相关引用:

npm publishes most files in your source directory by default, and people have been publishing shrinkwraps for years. We didn't want to break compatibility. With --save and shrinkwrap by default, there was a great risk of it accidentally making it in and propagating through the registry, and basically render our ability to update deps and dedupe... null.

So we chose a new name. And we chose a new name kind of all of a sudden. The new lockfile shares basically all of the same code, the exact same format

Explanation from NPM Developer:

The idea is definitely for package-lock.json to be the Latest and Greatest in shrinkwrap technology, and npm-shrinkwrap.json to be reserved for those precious few folks out there who care very much about their libraries having an exact node_modules -- and for people who want CI using npm@>=2 to install a particular tree without having to bump its npm version.

The new lockfile ("package-lock.json") shares basically all of the same code, the exact same format as npm-shrinkwrap (you can rename them between one another!). It's also something the community seems to understand: "it has a lockfile" seems to click so much faster with people. Finally, having a new file meant that we could have relatively low-risk backwards-compat with shrinkwrap without having to do weird things like allow-publication mentioned in the parent post.

这些文件具有完全相同的内容,但 npm 处理它们的方式存在一些差异,其中大部分都在 package-lock.json and npm-shrinkwrap.json:

的文档页面上注明
  • package-lock.json 永远不会发布到 npm,而 npm-shrinkwrap 默认是
  • package-lock.json 不在顶级包中的文件被忽略,但属于依赖项的 shrinkwrap 文件被尊重
  • npm-shrinkwrap.json 向后兼容 npm 版本 2、3 和 4,而 package-lock.json 只能被 npm 5+
  • 识别

您可以通过 运行 npm shrinkwrap.

将现有的 package-lock.json 转换为 npm-shrinkwrap.json

因此:

  • 如果您没有将包发布到 npm,那么在这两个文件之间进行选择并不重要。您可能希望使用 package-lock.json,因为它是默认值,而且它的名称对于 npm 初学者来说更清晰;或者,如果您难以确保开发团队中的每个人都使用 npm 5+,您可能希望使用 npm-shrinkwrap.json 来向后兼容 npm 2-4。 (请注意,npm 5 于 2017 年 5 月 25 日发布;从该日期开始,向后兼容性将变得越来越不重要,因为大多数人最终都会升级。)

  • 如果您正在将包发布到 npm,您可以选择:

    1. 使用 package-lock.json 准确记录您安装的依赖项版本,但允许安装您的包的​​人使用与您的 package.json 规定的版本范围兼容的任何版本的依赖项, 或
    2. 使用 npm-shrinkwrap.json 来保证安装您的包的​​每个人都获得 完全 相同版本的所有依赖项


    文档中描述的官方观点是选项 1 应该用于库(大概是为了减少当许多包的依赖项都依赖于略有不同的版本时引起的包重复量具有相同的次要依赖项),但选项 2 对于将要全局安装的可执行文件可能是合理的。

package-lock.json 版本只保证 npm ci ().

npm-shrinkwrap.json 版本保证 npm cinpm install