blocks|key|105808|text|它存储了一个精确的、版本化的依赖树，而不是像package.json本身那样使用星形版本控制(例如1.0.*)。这意味着您可以保证其他开发人员或prod版本等的依赖关系。它还具有锁定树的机制，但通常会在package.json更改时重新生成。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|105809|来自the+npm+docs|105810|105811|包--任何npm修改node_modules树或package.json的操作都会自动生成lock.json。它描述了生成的确切树，这样无论中间依赖项更新如何，后续安装都能够生成相同的树。|blockquote|105812|105813|此文件旨在提交到源代码库中，并用于各种用途：|105814|描述依赖关系树的单一表示，以确保队友、部署和持续集成安装完全相同的依赖关系。|105815|为用户“穿越”到node_modules以前的状态提供了便利，而不必提交目录本身。|105816|通过可读的源代码管理差异来促进树更改的更大可见性。|105817|并通过允许npm跳过以前安装的包的重复元数据解析来优化安装过程。“|105818|105819|编辑|105820|为了回答下面jrahhali关于只使用带有确切版本号的package.json的问题。请记住，package.json只包含直接依赖项，而不包含依赖项的依赖项(有时称为嵌套依赖项)。这意味着使用标准package.json无法控制这些嵌套依赖项的版本，直接引用它们或作为对等依赖项不会有任何帮助，因为您也无法控制直接依赖项为这些嵌套依赖项定义的版本容差。|105821|即使您锁定了直接依赖关系的版本，您也不能100%25保证您的完整依赖关系树每次都是相同的。其次，您可能希望允许直接依赖项的非破坏性更改(基于语义版本控制)，这会使您对嵌套依赖项的控制更少，而且您也不能保证直接依赖项在某些时候不会违反语义版本控制规则本身。|105822|所有这一切的解决方案是锁文件，如上所述，它在完整依赖关系树的版本中锁定。这允许您保证其他开发人员或版本的依赖关系树，同时仍然允许使用您的标准package.json测试新的依赖关系版本(直接或间接)。|105823|注意：前面的锁做了几乎相同的事情，但是锁文件重命名了它，这样它的功能就更清晰了。如果项目中已经存在压缩包装文件，则将使用该文件，而不是任何锁定文件。|105824|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.npmjs.com/files/package-lock.json^0|M|C|2T|C|0|2|C|0|0|0|0|0|0|0|0|0|0|0|0|R|C|1B|C|2R|C|0|0|1Y|C|0|0^^$0|@$1|2|3|4|5|6|7|1F|8|@$9|1G|A|1H|B|C]|$9|1I|A|1J|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1K|8|@]|D|@$9|1L|A|1M|1|1N]]|E|$]]|$1|H|3|-4|5|6|7|1O|8|@]|D|@]|E|$]]|$1|I|3|J|5|K|7|1P|8|@]|D|@]|E|$]]|$1|L|3|-4|5|6|7|1Q|8|@]|D|@]|E|$]]|$1|M|3|N|5|6|7|1R|8|@]|D|@]|E|$]]|$1|O|3|P|5|6|7|1S|8|@]|D|@]|E|$]]|$1|Q|3|R|5|6|7|1T|8|@]|D|@]|E|$]]|$1|S|3|T|5|6|7|1U|8|@]|D|@]|E|$]]|$1|U|3|V|5|6|7|1V|8|@]|D|@]|E|$]]|$1|W|3|-4|5|6|7|1W|8|@]|D|@]|E|$]]|$1|X|3|Y|5|6|7|1X|8|@]|D|@]|E|$]]|$1|Z|3|10|5|6|7|1Y|8|@$9|1Z|A|20|B|C]|$9|21|A|22|B|C]|$9|23|A|24|B|C]]|D|@]|E|$]]|$1|11|3|12|5|6|7|25|8|@]|D|@]|E|$]]|$1|13|3|14|5|6|7|26|8|@$9|27|A|28|B|C]]|D|@]|E|$]]|$1|15|3|16|5|6|7|29|8|@]|D|@]|E|$]]|$1|17|3|-4|5|6|7|2A|8|@]|D|@]|E|$]]]|18|$19|$5|1A|1B|1C|E|$1D|1E]]]]

It stores an exact, versioned dependency tree rather than using starred versioning like <code>package.json</code> itself (e.g. 1.0.*). This means you can guarantee the dependencies for other developers or prod releases, etc. It also has a mechanism to lock the tree but generally will regenerate if <code>package.json</code> changes.
From <a href="https://docs.npmjs.com/files/package-lock.json" rel="noreferrer">the npm docs</a>:
<blockquote>
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.
This file is intended to be committed into source repositories, and serves various purposes:
Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.
Provide a facility for users to &quot;time-travel&quot; to previous states of node_modules without having to commit the directory itself.
To facilitate greater visibility of tree changes through readable source control diffs.
And optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages.&quot;
</blockquote>
<h2>Edit</h2>
To answer jrahhali's question below about just using the <code>package.json</code> with exact version numbers. Bear in mind that your <code>package.json</code> contains only your direct dependencies, not the dependencies of your dependencies (sometimes called nested dependencies). This means with the standard <code>package.json</code> you can't control the versions of those nested dependencies, referencing them directly or as peer dependencies won't help as you also don't control the version tolerance that your direct dependencies define for these nested dependencies.
Even if you lock down the versions of your direct dependencies you cannot 100% guarantee that your full dependency tree will be identical every time. Secondly you might want to allow non-breaking changes (based on semantic versioning) of your direct dependencies which gives you even less control of nested dependencies plus you again can't guarantee that your direct dependencies won't at some point break semantic versioning rules themselves.
The solution to all this is the lock file which as described above locks in the versions of the full dependency tree. This allows you to guarantee your dependency tree for other developers or for releases whilst still allowing testing of new dependency versions (direct or indirect) using your standard <code>package.json</code>.
NB. The previous <a href="https://docs.npmjs.com/cli/v7/configuring-npm/npm-shrinkwrap-json" rel="noreferrer"><code>npm-shrinkwrap.json</code></a> did pretty much the same thing but the lock file renames it so that it's function is clearer. If there's already a shrink wrap file in the project then this will be used instead of any lock file.

blocks|key|105833|text|这是对npm的一个非常重要的改进：保证每个包的版本完全相同。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|105834|如何确保您的项目在不同的时间在不同的环境中使用相同的包构建？比方说，你可以在你的package.json中使用%5E1.2.3，或者你的一些依赖项正在以这种方式使用，但是你如何确保每次npm+install在你的开发机器和构建服务器中获得相同的版本？|CODE|105835|npm+install将重新生成锁定文件。|105836|当在构建服务器或部署服务器上时，执行npm+ci|105837|(它将读取锁定文件，并安装整个包树)|105838|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.npmjs.com/cli/install|1|https://docs.npmjs.com/cli/ci.html^0|H|5|0|14|C|1J|6|2I|B|0|0|B|0|B|0|0|I|6|I|6|1|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|11|8|@$9|12|A|13|B|H]|$9|14|A|15|B|H]|$9|16|A|17|B|H]]|D|@]|E|$]]|$1|I|3|J|5|6|7|18|8|@$9|19|A|1A|B|H]]|D|@$9|1B|A|1C|1|1D]]|E|$]]|$1|K|3|L|5|6|7|1E|8|@$9|1F|A|1G|B|H]]|D|@$9|1H|A|1I|1|1J]]|E|$]]|$1|M|3|N|5|6|7|1K|8|@]|D|@]|E|$]]|$1|O|3|-4|5|6|7|1L|8|@]|D|@]|E|$]]]|P|$Q|$5|R|S|T|E|$U|V]]|W|$5|R|S|T|E|$U|X]]]]

It's an very important improvement for npm: guarantee exact same version of every package.
How to make sure your project built with same packages in different environments in a different time? Let's say, you may use <code>^1.2.3</code> in your <code>package.json</code>, or some of your dependencies are using that way, but how can you ensure each time <code>npm install</code> will pick up same version in your dev machine and in the build server? package-lock.json will ensure that.
<a href="https://docs.npmjs.com/cli/install" rel="noreferrer"><code>npm install</code></a> will re-generate the lock file. 
When on build server or deployment server, do <a href="https://docs.npmjs.com/cli/ci.html" rel="noreferrer"><code>npm ci</code></a> 
(which will read from the lock file, and install the whole package tree)

blocks|key|2853500|text|当在package.json中更改属性(如"version“属性或依赖项属性)中的数值时，将写入package-lock.json。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2853501|如果package.json和package-lock.json中的这些数值匹配，则从中读取package-lock.json。|2853502|如果package.json和package-lock.json中的这些数值不匹配，则会使用这些新值和新修饰符(如插入符号和波浪符号)写入package-lock.json。但正是数字触发了对package-lock.json的更改。|2853503|要理解我的意思，请执行以下操作。在不使用package-lock.json的情况下使用package.json，使用以下命令运行npm+install：|2853504|{
++"name":+"test",
++"version":+"1.0.0",
++...
++"devDependencies":+{
++++"sinon":+"7.2.2"
++}
}|code-block|syntax|javascript|2853505|package-lock.json现在将拥有：|2853506|"sinon":+{
++"version":+"7.2.2",|2853507|现在将这两个文件复制/粘贴到一个新目录。将package.json更改为(仅添加插入符号)：|2853508|{
++"name":+"test",
++"version":+"1.0.0",
++...
++"devDependencies":+{
++++"sinon":+"%5E7.2.2"
++}
}|2853509|运行npm+install。如果没有package-lock.json文件，则会安装sinon@7.3.0。npm+install是从+package-lock.json读取并安装7.2.2的。|BOLD|2853510|现在将package.json更改为：|2853511|{
++"name":+"test",
++"version":+"1.0.0",
++...
++"devDependencies":+{
++++"sinon":+"%5E7.3.0"
++}
}|2853512|运行npm+install。package-lock.json已被写入，现在将显示：|2853513|"sinon":+{
++"version":+"%5E7.3.0",|2853514|entityMap^0|2|C|1C|H|0|2|C|F|H|1A|H|0|2|C|F|H|1X|H|2O|H|0|K|H|17|C|1S|B|0|0|0|H|0|0|L|C|0|0|2|B|I|H|1I|B|1W|H|2O|1|0|0|J|3|C|0|0|0|16|2|B|E|H|0|0^^$0|@$1|2|3|4|5|6|7|1B|8|@$9|1C|A|1D|B|C]|$9|1E|A|1F|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1G|8|@$9|1H|A|1I|B|C]|$9|1J|A|1K|B|C]|$9|1L|A|1M|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1N|8|@$9|1O|A|1P|B|C]|$9|1Q|A|1R|B|C]|$9|1S|A|1T|B|C]|$9|1U|A|1V|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|1W|8|@$9|1X|A|1Y|B|C]|$9|1Z|A|20|B|C]|$9|21|A|22|B|C]]|D|@]|E|$]]|$1|L|3|M|5|N|7|23|8|@]|D|@]|E|$O|P]]|$1|Q|3|R|5|6|7|24|8|@$9|25|A|26|B|C]]|D|@]|E|$]]|$1|S|3|T|5|N|7|27|8|@]|D|@]|E|$O|P]]|$1|U|3|V|5|6|7|28|8|@$9|29|A|2A|B|C]]|D|@]|E|$]]|$1|W|3|X|5|N|7|2B|8|@]|D|@]|E|$O|P]]|$1|Y|3|Z|5|6|7|2C|8|@$9|2D|A|2E|B|C]|$9|2F|A|2G|B|C]|$9|2H|A|2I|B|C]|$9|2J|A|2K|B|C]|$9|2L|A|2M|B|10]]|D|@]|E|$]]|$1|11|3|12|5|6|7|2N|8|@$9|2O|A|2P|B|10]|$9|2Q|A|2R|B|C]]|D|@]|E|$]]|$1|13|3|14|5|N|7|2S|8|@]|D|@]|E|$O|P]]|$1|15|3|16|5|6|7|2T|8|@$9|2U|A|2V|B|10]|$9|2W|A|2X|B|C]|$9|2Y|A|2Z|B|C]]|D|@]|E|$]]|$1|17|3|18|5|N|7|30|8|@]|D|@]|E|$O|P]]|$1|19|3|-4|5|6|7|31|8|@]|D|@]|E|$]]]|1A|$]]

<code>package-lock.json</code> is written to when a numerical value in a property such as the "version" property, or a dependency property is changed in <code>package.json</code>.

If these numerical values in <code>package.json</code> and <code>package-lock.json</code> match, <code>package-lock.json</code> is read from.

If these numerical values in <code>package.json</code> and <code>package-lock.json</code> do not match, <code>package-lock.json</code> is written to with those new values, and new modifiers such as the caret and tilde if they are present. But it is the numeral that is triggering the change to <code>package-lock.json</code>.

To see what I mean, do the following. Using <code>package.json</code> without <code>package-lock.json</code>, run <code>npm install</code> with:

<pre><code>{
 "name": "test",
 "version": "1.0.0",
 ...
 "devDependencies": {
 "sinon": "7.2.2"
 }
}
</code></pre>

<code>package-lock.json</code> will now have:

<pre><code>"sinon": {
 "version": "7.2.2",
</code></pre>

Now copy/paste both files to a new directory. Change <code>package.json</code> to (only adding caret):

<pre><code>{
 "name": "test",
 "version": "1.0.0",
 ...
 "devDependencies": {
 "sinon": "^7.2.2"
 }
}
</code></pre>

run <code>npm install</code>. If there were no <code>package-lock.json</code> file, sinon@7.3.0 would be installed. <code>npm install</code> is reading from <code>package-lock.json</code> and installing 7.2.2. 

Now change <code>package.json</code> to: 

<pre><code>{
 "name": "test",
 "version": "1.0.0",
 ...
 "devDependencies": {
 "sinon": "^7.3.0"
 }
}
</code></pre>

run <code>npm install</code>. <code>package-lock.json</code> has been written to, and will now show:

<pre><code>"sinon": {
 "version": "^7.3.0",
</code></pre>

blocks|key|2853519|text|对于npm修改node_modules树或package.json的任何操作，都会自动生成package-lock.json。它描述了生成的确切树，这样无论中间依赖项更新如何，后续安装都能够生成相同的树。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2853520|它描述了依赖关系树的单一表示，从而保证队友、部署和持续集成安装完全相同的包含以下属性的dependencies.It。|2853521|{
++++"name":+"mobileapp",
++++"version":+"1.0.0",
++++"lockfileVersion":+1,
++++"requires":+true,
++++"dependencies":+{
++++"@angular-devkit/architect":+{
++++++"version":+"0.11.4",
++++++"resolved":+"https://registry.npmjs.org/@angular-+devkit/architect/-/architect-0.11.4.tgz",
++++++"integrity":+"sha512-2zi6S9tPlk52vyqNFg==",
++++++"dev":+true,
++++++"requires":+{
++++++++"@angular-devkit/core":+"7.1.4",
++++++++"rxjs":+"6.3.3"
++++++}
++++},
}+++++++|code-block|syntax|javascript|2853522|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|M|8|@]|9|@]|A|$G|H]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

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.
It describes a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.It contains the following properties.
<pre><code>{
 &quot;name&quot;: &quot;mobileapp&quot;,
 &quot;version&quot;: &quot;1.0.0&quot;,
 &quot;lockfileVersion&quot;: 1,
 &quot;requires&quot;: true,
 &quot;dependencies&quot;: {
 &quot;@angular-devkit/architect&quot;: {
 &quot;version&quot;: &quot;0.11.4&quot;,
 &quot;resolved&quot;: &quot;https://registry.npmjs.org/@angular- devkit/architect/-/architect-0.11.4.tgz&quot;,
 &quot;integrity&quot;: &quot;sha512-2zi6S9tPlk52vyqNFg==&quot;,
 &quot;dev&quot;: true,
 &quot;requires&quot;: {
 &quot;@angular-devkit/core&quot;: &quot;7.1.4&quot;,
 &quot;rxjs&quot;: &quot;6.3.3&quot;
 }
 },
} 
</code></pre>

blocks|key|2853531|text|还有一件重要的事要提，那就是包锁文件带来的安全性改进。由于它保留了包的所有散列，如果有人篡改公共npm注册表并更改包的源代码，甚至不更改包本身的版本，它将被包锁文件检测到。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2853532|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

One important thing to mention as well is the security improvement that comes with the package-lock file. Since it keeps all the hashes of the packages if someone would tamper with the public npm registry and change the source code of a package without even changing the version of the package itself it would be detected by the package-lock file.

blocks|key|102985|text|此文件由npm自动创建并使用，用于跟踪包安装，并更好地管理项目依赖项的状态和历史记录。您不应更改此文件的内容。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|102986|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

This file is automatically created and used by npm to keep track of your package installations
and to better manage the state and history of your project’s dependencies. You
shouldn’t alter the contents of this file.

blocks|key|103468|text|package-lock.json：它包含当前为应用程序安装的确切版本详细信息。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|103469|entityMap^0|0|H|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

<code>package-lock.json</code>: It contains the exact version details that is currently installed for your Application.

blocks|key|2641914|text|package-lock.json文件的目标是跟踪安装的每个包的确切版本，这样即使包的维护者更新了包，产品也可以以相同的方式100%25地重现。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2641915|这解决了package.json没有解决的一个非常具体的问题。在package.json中，您可以使用semver符号设置要升级到的版本(补丁或次要版本)。|2641916|entityMap^0|0|H|0|4|C|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|P|8|@]|D|@]|E|$]]]|I|$]]

The goal of <code>package-lock.json</code> file is to keep track of the exact version of every package that is installed so that a product is 100% reproducible in the same way even if packages are updated by their maintainers.
This solves a very specific problem that <code>package.json</code>left unsolved. In package.json you can set which versions you want to upgrade to (patch or minor), using the semver notation.

blocks|key|103011|text|Package.json文件包含您安装的包和库的主要名称，您可以对其进行编辑，但是Package-lock.json包含每个包的详细信息和每个包的存储库链接(假设它是来自package.json的包的详细信息)参考|type|unstyled|depth|inlineStyleRanges|entityRanges|data|103012|https://web-brackets.com/discussion/69/what-is-the-use-of-package-lock-json-file|offset|length|103013|entityMap|0|LINK|mutability|MUTABLE|url|https://web-brackets.com/discussion/69/what-is-the-use-of-package-lock-json-file-^0|0|0|28|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

Package.json file contains the main names of packages &amp; libraries which you installed and you can edit it, but Package-lock.json contains the details of each package and the link of repository of each package (consider it's the details of the packages which came from package.json) Reference
<a href="https://web-brackets.com/discussion/69/what-is-the-use-of-package-lock-json-file-" rel="nofollow noreferrer">https://web-brackets.com/discussion/69/what-is-the-use-of-package-lock-json-file</a>

npm@5 has been published, it has a new feature <code>package-lock.json</code> file (after <code>npm install</code>) which confuses me. I want to know, what is the effect of this file?

What is the role of the package-lock.json?

服务器

npm@5已经发布了，它有一个新的功能package-lock.json文件(在npm install之后)，这让我很困惑。我想知道，这个文件的效果是什么？

问包-lock.json的作用是什么？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问包-lock.json的作用是什么？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问包-lock.json的作用是什么？
EN