是否提交由npm 5创建的package-lock.json文件？
npm
5已于今天发布
，其中一项新功能包括通过创建package- lock.json文件进行确定性安装。
该文件应该保留在源代码管理中吗？
我假设它类似于yarn.lock和composer.lock，这两个都应该保留在源代码管理中。
问题答案：
是的，package-lock.json旨在被检查到源代码管理中。如果您使用的是npm 5，则可能会在命令行上看到：created a lockfile as package-lock.json. You should commit this file.根据npm help package-lock.json：
package- lock.json会为npm修改node_modules树或的任何操作自动生成package.json。它描述了生成的确切树，因此无论中间依赖项更新如何，后续安装都可以生成相同的树。该文件旨在提交到源存储库中 ，并具有多种用途：
描述依赖关系树的单个表示，这样可以确保队友，部署和持续集成安装完全相同的依赖关系。
为用户提供一种工具，使其可以“时间旅行”到以前的状态，
node_modules而不必提交目录本身。为了通过可读的源代码控制差异更好地了解树的变化。
并允许npm跳过先前安装的软件包的重复元数据解析，从而优化安装过程。
关于
package-lock.json它的一个关键细节是它无法发布，并且如果在顶级软件包之外的任何地方找到它，它将被忽略。它与npm-
shrinkwrap.json（5）共享一种格式，该格式本质上是相同的文件，但允许发布。除非部署CLI工具或使用发布过程来生产生产软件包，否则不建议这样做。如果软件包的根目录中同时存在
package-lock.json和npm-shrinkwrap.json，package- lock.json将被完全忽略。
-
问题内容： 要锁定项目上安装的依赖项的版本，该命令将创建一个名为的文件。这是从Node.js v8.0.0和npm v5.0.0开始的 ，您可能已经知道了。 尽管有Node.js和npm关于提交此文件的建议，但是关于何时应避免这样做的一些担忧也是一个选择。通常，我们致力于项目，但这是一个奇特的问题。 虽然我们默认情况下应该提交文件，但是我们有一个特定的情况，我们不应该提交。例如，如果我们要测试项目
-
npm@5已经发布，它有一个新的功能文件（在之后），这让我很困惑。我想知道，这个文件有什么效果？
-
有没有办法检查一个文件是否与兼容，而不运行？兼容意味着指定的版本可以通过来实现。 当前方法 我目前正在通过运行并检查是否更改为： 用例 我想在持续集成中添加一个测试，以确保如果开发人员修改了，他们也会相应地更新。这一点很重要的原因是我们的持续集成使用了，而不是仅引用，因此如果开发人员不更新锁文件，持续集成设置将与他们期望的不匹配。
-
我正在学习使用Node.js和express框架的后端。我通过添加了模块。几个小时后，我注意到我的项目不包含package.json文件。 我现在尝试添加测试命令来使用nodemon。比如。但是在package-lock.json文件中没有这样的部分。 我不想再从头开始。
-
所以，我有这个包裹，在package-lock.json里面： 该漏洞是：“大括号”：“^1.8.2”，当我运行npm audit时，它表示已修复为2.3。1，但我似乎无法更新它，或者只是不知道如何更新。 我尝试过的事情： npm安装micromatch和支架，然后进行npm审计修复 npm安装 从npm依赖关系中，可能有一些事情我不理解。那么我该如何解决这个问题呢？ 为软件包编辑。json
-
我们在报告错误的工作中已经创建了可重复使用的模式，为什么不把它打包让 Meteor 社区的其他人都可使用呢？ 为了开始，我们需要一个 Meteor 开发者账号。你可以从申请，但是很有可能当你注册这本书的时候已经得到了。不管哪种情况，你应该搞清楚你的用户名是什么，因为我们会在本章中大量使用它。 在本章中我们使用用户名 tmeasday，当然你也可以换成你自己的。 首先我们需要创建一个结构来存放新的包