[英]Do I commit the package-lock.json file created by npm 5?
npm 5 was released today and one of the new features include deterministic installs with the creation of a package-lock.json
file. npm 5 今天发布,其中一项新功能包括确定性安装以及创建package-lock.json
文件。
Is this file supposed to be kept in source control?这个文件应该保存在源代码管理中吗?
I'm assuming it's similar to yarn.lock
and composer.lock
, both of which are supposed to be kept in source control.我假设它类似于yarn.lock
和composer.lock
,两者都应该保存在源代码管理中。
Yes, package-lock.json
is intended to be checked into source control.是的, package-lock.json
旨在检查到源代码控制中。 If you're using npm 5+, you may see this notice on the command line: created a lockfile as package-lock.json. You should commit this file.
如果您使用的是 npm 5+,您可能会在命令行上看到此通知: created a lockfile as package-lock.json. You should commit this file.
created a lockfile as package-lock.json. You should commit this file.
According tonpm help package-lock.json
:根据npm help package-lock.json
:
package-lock.json
is automatically generated for any operations where npm modifies either thenode_modules
tree, orpackage.json
.package-lock.json
会为 npm 修改node_modules
树或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 "time-travel" to previous states of
node_modules
without having to commit the directory itself.为用户提供“时间旅行”到node_modules
先前状态的工具,而无需提交目录本身。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.并通过允许 npm 跳过以前安装的包的重复元数据解析来优化安装过程。
One key detail about
package-lock.json
is that it cannot be published, and it will be ignored if found in any place other than the toplevel package.关于package-lock.json
的一个关键细节是它无法发布,如果在顶级包以外的任何地方找到它,它将被忽略。 It shares a format with npm-shrinkwrap.json, which is essentially the same file, but allows publication.它与 npm-shrinkwrap.json 共享格式,本质上是相同的文件,但允许发布。 This is not recommended unless deploying a CLI tool or otherwise using the publication process for producing production packages.除非部署 CLI 工具或以其他方式使用发布过程来生成生产包,否则不建议这样做。If both
package-lock.json
andnpm-shrinkwrap.json
are present in the root of a package,package-lock.json
will be completely ignored.如果package-lock.json
和npm-shrinkwrap.json
shrinkwrap.json 都存在于包的根目录中,则package-lock.json
将被完全忽略。
Yes, you SHOULD:是的你应该:
package-lock.json
.提交package-lock.json
。npm ci
instead of npm install
when building your applications both on your CI and your local development machine在 CI 和本地开发机器上构建应用程序时,使用npm ci
而不是npm install
The npm ci
workflow requires the existence of a package-lock.json
. npm ci
工作流程需要存在package-lock.json
。
A big downside of npm install
command is its unexpected behavior that it may mutate the package-lock.json
, whereas npm ci
only uses the versions specified in the lockfile and produces an error npm install
命令的一大缺点是它可能会改变package-lock.json
的意外行为,而npm ci
仅使用锁定文件中指定的版本并产生错误
package-lock.json
and package.json
are out of sync如果package-lock.json
和package.json
不同步package-lock.json
is missing.如果package-lock.json
丢失。 Hence, running npm install
locally, esp.因此,在本地运行npm install
,尤其是。 in larger teams with multiple developers, may lead to lots of conflicts within the package-lock.json
and developers to decide to completely delete the package-lock.json
instead.在有多个开发人员的大型团队中,可能会导致package-lock.json
内部发生大量冲突,并且开发人员决定完全删除package-lock.json
。
Yet there is a strong use-case for being able to trust that the project's dependencies resolve repeatably in a reliable way across different machines.然而,有一个强大的用例可以相信项目的依赖关系在不同机器上以可靠的方式可重复地解决。
From a package-lock.json
you get exactly that: a known-to-work state.从package-lock.json
你得到的正是:一个已知的工作状态。
In the past, I had projects without package-lock.json
/ npm-shrinkwrap.json
/ yarn.lock
files whose build would fail one day because a random dependency got a breaking update.过去,我的项目没有package-lock.json
/ npm-shrinkwrap.json
shrinkwrap.json / yarn.lock
文件,它们的构建有一天会失败,因为随机依赖项得到了破坏性更新。
Those issue are hard to resolve as you sometimes have to guess what the last working version was.这些问题很难解决,因为您有时不得不猜测最后一个工作版本是什么。
If you want to add a new dependency, you still run npm install {dependency}
.如果你想添加一个新的依赖,你仍然运行npm install {dependency}
。 If you want to upgrade, use either npm update {dependency}
or npm install ${dependendency}@{version}
and commit the changed package-lock.json
.如果要升级,请使用npm update {dependency}
或npm install ${dependendency}@{version}
并提交更改后的package-lock.json
。
If an upgrade fails, you can revert to the last known working package-lock.json
.如果升级失败,您可以恢复到最后一个已知的工作package-lock.json
。
To quote npm doc :引用 npm doc :
It is highly recommended you commit the generated package lock to source control: this will allow anyone else on your team, your deployments, your CI/continuous integration, and anyone else who runs npm install in your package source to get the exact same dependency tree that you were developing on.强烈建议您将生成的包锁定提交到源代码控制:这将允许您团队中的其他任何人、您的部署、您的 CI/持续集成以及在您的包源中运行 npm install 的任何其他人获得完全相同的依赖关系树你正在开发的。 Additionally, the diffs from these changes are human-readable and will inform you of any changes npm has made to your node_modules, so you can notice if any transitive dependencies were updated, hoisted, etc.此外,这些更改的差异是人类可读的,并且会通知您 npm 对您的 node_modules 所做的任何更改,因此您可以注意到是否有任何传递依赖项被更新、提升等。
And in regards to the difference between npm ci
vs npm install
:关于npm ci
与npm install
之间的区别:
- The project must have an existing package-lock.json or npm-shrinkwrap.json.该项目必须具有现有的 package-lock.json 或 npm-shrinkwrap.json。
- If dependencies in the package lock do not match those in package.json,
npm ci
will exit with an error, instead of updating the package lock.如果包锁中的依赖项与 package.json 中的依赖项不匹配,npm ci
将退出并报错,而不是更新包锁。npm ci
can only install entire projects at a time: individual dependencies cannot be added with this command.npm ci
一次只能安装整个项目:无法使用此命令添加单个依赖项。- If a
node_modules
is already present, it will be automatically removed beforenpm ci
begins its install.如果node_modules
已经存在,它将在npm ci
开始安装之前自动删除。- It will never write to
package.json
or any of the package-locks: installs are essentially frozen.它永远不会写入package.json
或任何包锁:安装基本上是冻结的。
Yes, it's intended to be checked in. I want to suggest that it gets its own unique commit.是的,它打算被签入。我想建议它有自己独特的提交。 We find that it adds a lot of noise to our diffs.我们发现它给我们的差异增加了很多噪音。
Yes, the best practice is to check-in (YES, CHECK-IN)是的,最佳做法是办理登机手续(YES,CHECK-IN)
I agree that it will cause a lot of noise or conflict when seeing the diff.我同意在看到差异时会引起很多噪音或冲突。 But the benefits are:但好处是:
^1.2.3
in your package.json
, but how can you ensure each time npm install
will pick up the same version in your dev machine and in the build server, especially those indirect dependency packages?您可以在package.json
中使用^1.2.3
,但是如何确保每次npm install
都会在您的开发机器和构建服务器中获取相同的版本,尤其是那些间接依赖包? Well, package-lock.json
will ensure that.好吧, package-lock.json
将确保这一点。 (With the help of npm ci
which installs packages based on lock file) (借助npm ci
安装基于锁定文件的软件包)npm audit fix
(I think the audit feature is from npm version 6).它有助于新的审计功能npm audit fix
(我认为审计功能来自 npm 版本 6)。I don't commit this file in my projects.我不在我的项目中提交这个文件。 What's the point ?重点是什么 ?
Though it's true that I never use ^ in my package.json for libs because I had bad experiences with it.虽然我确实从未在我的 package.json 中使用 ^ 作为库,因为我对它有不好的体验。
To the people complaining about the noise when doing git diff:对于在执行 git diff 时抱怨噪音的人:
git diff -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'
What I did was use an alias:我所做的是使用别名:
alias gd="git diff --ignore-all-space --ignore-space-at-eol --ignore-space-change --ignore-blank-lines -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'"
To ignore package-lock.json in diffs for the entire repository (everyone using it), you can add this to .gitattributes
:要在整个存储库(每个使用它的人)的差异中忽略 package-lock.json,您可以将其添加到.gitattributes
:
package-lock.json binary
yarn.lock binary
This will result in diffs that show "Binary files a/package-lock.json and b/package-lock.json differ whenever the package lock file was changed. Additionally, some Git services (notably GitLab, but not GitHub) will also exclude these files (no more 10k lines changed!) from the diffs when viewing online when doing this.这将导致差异显示“无论何时更改包锁定文件,二进制文件 a/package-lock.json 和 b/package-lock.json 都会有所不同。此外,一些 Git 服务(尤其是 GitLab,但不是 GitHub)也将排除执行此操作时在线查看这些文件(不再更改 10k 行!)。
Yes, you can commit this file.是的,您可以提交此文件。 From the npm's official docs :来自npm 的官方文档:
package-lock.json
is automatically generated for any operations wherenpm
modifies either thenode_modules
tree, orpackage.json
.package-lock.json
会为npm
修改node_modules
树或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[.]该文件旨在提交到源存储库[.]
Yes, it's a standard practice to commit package-lock.json
.是的,提交package-lock.json
是一种标准做法。
The main reason for committing package-lock.json
is that everyone in the project is on the same package version.提交package-lock.json
是项目中的每个人都在同一个包版本上。
Pros:优点:
Cons:缺点:
npm install
won't make sure that everyone in the project is on the same package version. npm install
不会确保项目中的每个人都使用相同的包版本。 npm ci
will help with this. npm ci
将对此有所帮助。
Disable package-lock.json globally全局禁用 package-lock.json
type the following in your terminal:在终端中输入以下内容:
npm config set package-lock false
this really work for me like magic这真的像魔术一样对我有用
All answers say "YES" but that also depend of the project, the doc says:所有答案都说“是”,但这也取决于项目,文档说:
One key detail about package-lock.json is that it cannot be published, and it will be ignored if found in any place other than the toplevel package.关于 package-lock.json 的一个关键细节是它无法发布,如果在顶级包以外的任何地方找到它,它将被忽略。
This mean that you don't need to publish on npm your package-lock.json
for dependency but you need to use package-lock.json
in your repo to lock the version of your test dependency, build dependencies…这意味着您不需要在 npm 上发布您的package-lock.json
以获取依赖项,但您需要在您的仓库中使用package-lock.json
来锁定您的测试依赖项的版本,构建依赖项......
However, If your are using lerna for managing projects with multiple packages, you should put the package.json
only on the root of your repo, not in each subpackage are created with npm init
.但是,如果您使用lerna管理具有多个包的项目,则应仅将package.json
放在 repo 的根目录中,而不是在每个子包中使用npm init
创建。 You will get something like that :你会得到类似的东西:
.git
lerna.json
package.json
package-lock.json <--- here
packages/a/package.json
packages/a/lib/index.js
packages/b/package.json
packages/b/lib/index.js
My use of npm is to generate minified/uglified css/js and to generate the javascript needed in pages served by a django application.我对 npm 的使用是生成缩小/丑化 css/js 并生成 django 应用程序提供的页面中所需的 javascript。 In my applications, Javascript runs on the page to create animations, some times perform ajax calls, work within a VUE framework and/or work with the css.在我的应用程序中,Javascript 在页面上运行以创建动画,有时执行 ajax 调用,在 VUE 框架内工作和/或使用 css。 If package-lock.json has some overriding control over what is in package.json, then it may be necessary that there is one version of this file.如果 package-lock.json 对 package.json 中的内容有一些压倒一切的控制,那么可能需要此文件的一个版本。 In my experience it either does not effect what is installed by npm install, or if it does, It has not to date adversely affected the applications I deploy to my knowledge.根据我的经验,它要么不会影响 npm install 安装的内容,要么如果确实如此,据我所知,它迄今为止还没有对我部署的应用程序产生不利影响。 I don't use mongodb or other such applications that are traditionally thin client.我不使用传统上是瘦客户端的 mongodb 或其他此类应用程序。
I remove package-lock.json from repo because npm install generates this file, and npm install is part of the deploy process on each server that runs the app.我从 repo 中删除了 package-lock.json,因为 npm install 会生成这个文件,并且 npm install 是运行应用程序的每台服务器上部署过程的一部分。 Version control of node and npm are done manually on each server, but I am careful that they are the same. node 和 npm 的版本控制是在每台服务器上手动完成的,但我注意它们是相同的。
When npm install
is run on the server, it changes package-lock.json, and if there are changes to a file that is recorded by the repo on the server, the next deploy WONT allow you to pull new changes from origin.当npm install
在服务器上运行时,它会更改 package-lock.json,如果服务器上的 repo 记录的文件发生更改,下一次部署不会允许您从源中提取新更改。 That is you can't deploy because the pull will overwrite the changes that have been made to package-lock.json.那就是您无法部署,因为拉取将覆盖对 package-lock.json 所做的更改。
You can't even overwrite a locally generated package-lock.json with what is on the repo (reset hard origin master), as npm will complain when ever you issue a command if the package-lock.json does not reflect what is in node_modules due to npm install, thus breaking the deploy.您甚至不能用 repo 上的内容覆盖本地生成的 package-lock.json(重置硬源主控),因为如果 package-lock.json 不反映其中的内容,那么当您发出命令时 npm 会抱怨node_modules 由于 npm install,从而破坏了部署。 Now if this indicates that slightly different versions have been installed in node_modules, once again that has never caused me problems.现在,如果这表明 node_modules 中安装了稍微不同的版本,那么这又一次没有给我带来问题。
If node_modules is not on your repo (and it should not be), then package-lock.json should be ignored.如果 node_modules 不在你的 repo 上(它不应该在),那么 package-lock.json 应该被忽略。
If I am missing something, please correct me in the comments, but the point that versioning is taken from this file makes no sense.如果我遗漏了什么,请在评论中纠正我,但是从这个文件中获取版本控制这一点是没有意义的。 The file package.json has version numbers in it, and I assume this file is the one used to build packages when npm install occurs, as when I remove it, npm install complains as follows:文件 package.json 中有版本号,我假设这个文件是在 npm install 发生时用于构建包的文件,当我删除它时,npm install 抱怨如下:
jason@localhost:introcart_wagtail$ rm package.json
jason@localhost:introcart_wagtail$ npm install
npm WARN saveError ENOENT: no such file or directory, open '/home/jason/webapps/introcart_devtools/introcart_wagtail/package.json'
and the build fails, however when installing node_modules or applying npm to build js/css, no complaint is made if I remove package-lock.json并且构建失败,但是在安装 node_modules 或应用 npm 构建 js/css 时,如果我删除 package-lock.json 则不会产生任何投诉
jason@localhost:introcart_wagtail$ rm package-lock.json
jason@localhost:introcart_wagtail$ npm run dev
> introcart@1.0.0 dev /home/jason/webapps/introcart_devtools/introcart_wagtail
> NODE_ENV=development webpack --progress --colors --watch --mode=development
10% building 0/1 modules 1 active ...
Committing package-lock.json to the source code version control means that the project will use a specific version of dependencies that may or may not match those defined in package.json.将 package-lock.json 提交到源代码版本控制意味着项目将使用特定版本的依赖项,这些依赖项可能与 package.json 中定义的那些匹配,也可能不匹配。 while the dependency has a specific version without any Caret (^) and Tilde (~) as you can see, that's mean the dependency will not be updated to the most recent version.虽然依赖项有一个特定版本,但没有任何插入符号 (^) 和波浪号 (~),如您所见,这意味着依赖项不会更新到最新版本。 and npm install will pick up the same version as well as we need it for our current version of Angular.并且 npm install 将选择相同的版本,以及我们当前版本的 Angular 所需要的版本。
Note : package-lock.json highly recommended to commit it IF I added any Caret (^) and Tilde (~) to the dependency to be updated during the CI.注意:如果我在 CI 期间将任何插入符号 (^) 和波浪号 (~) 添加到要更新的依赖项中,强烈建议将 package-lock.json 提交。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.