blocks|key|4358511|text|是的，是要办理登机手续的。我想建议它有自己的唯一提交。我们发现它给我们的diffs增加了很多噪音。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4358512|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|$]]

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.

blocks|key|4358624|text|对于那些在做git+diff时抱怨噪音的人：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4358625|git+diff+--+.+':(exclude)*package-lock.json'+--+.+':(exclude)*yarn.lock'|code-block|syntax|javascript|4358626|我所做的就是使用一个别名：|4358627|alias+gd="git+diff+--ignore-all-space+--ignore-space-at-eol+--ignore-space-change+--ignore-blank-lines+--+.+':(exclude)*package-lock.json'+--+.+':(exclude)*yarn.lock'"|4358628|要忽略整个存储库(每个人都在使用它)的diffs中的package-lock.json，可以将以下代码添加到.gitattributes中|offset|length|style|CODE|4358629|package-lock.json+binary
yarn.lock+binary|4358630|这将导致差异，显示“二进制文件a/+package+-lock.json和b/package-lock.json不同的包锁文件。此外，一些Git服务(特别是GitLab，但不是GitHub)也会排除这些文件(不超过10k行的变化！)，当在线查看时，这样做。|4358631|entityMap^0|0|0|0|0|1I|E|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Y|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|Z|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|10|8|@$M|11|N|12|O|P]]|9|@]|A|$]]|$1|Q|3|R|5|D|7|13|8|@]|9|@]|A|$E|F]]|$1|S|3|T|5|6|7|14|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|V|$]]

To the people complaining about the noise when doing git diff:

<pre><code>git diff -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'
</code></pre>

What I did was use an alias:

<pre><code>alias gd="git diff --ignore-all-space --ignore-space-at-eol --ignore-space-change --ignore-blank-lines -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'"
</code></pre>

To ignore package-lock.json in diffs for the entire repository (everyone using it), you can add this to <code>.gitattributes</code>:

<pre><code>package-lock.json binary
yarn.lock binary
</code></pre>

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.

blocks|key|4358707|text|我使用npm来生成缩小/丑化的css/js，并生成django应用程序所服务的页面中所需的javascript。在我的应用程序中，Javascript在页面上运行以创建动画，有时执行ajax调用，在VUE框架内工作和/或使用css。如果package-lock.json对package.json中的内容有一些覆盖控制，那么这个文件可能有必要只有一个版本。根据我的经验，它要么不会影响npm+install安装的内容，要么就算有影响，也不会对我所部署的应用程序产生负面影响。我不使用mongodb或其他类似的传统瘦客户端应用程序。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4358708|我从repo中删除了package-lock.json，因为npm+install会生成这个文件，npm+install是运行该应用程序的每台服务器上部署过程的一部分。node和npm的版本控制是在每台服务器上手动完成的，但我要注意它们是相同的。|4358709|当npm+install在服务器上运行时，它会更改包-lock.json，如果服务器上的存储库记录的文件有更改，则下一次部署将不允许您从原始位置提取新的更改。也就是说，您不能部署，因为拉取将覆盖对package-lock.json所做的更改。|offset|length|style|CODE|4358710|你甚至不能用repo+(重置硬源主机)上的东西覆盖本地生成的包-lock.json，因为npm会在你发出命令时抱怨，如果包-lock.json由于npm安装而没有反映node_modules中的内容，从而破坏部署。现在，如果这表明在node_modules中安装了略微不同的版本，再一次地，这从来没有给我带来问题。|4358711|如果node_modules不在您的存储库中(也不应该在其中)，那么应该忽略package-lock.json。|4358712|如果我遗漏了什么，请在注释中纠正我，但是版本控制是从这个文件中获取的这一点没有任何意义。文件package.json中有版本号，我假设这个文件就是在npm+install发生时用来构建包的文件，因为当我删除它时，npm+install会抱怨如下：|4358713|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'|code-block|syntax|javascript|4358714|但是，当安装node_modules或应用npm来构建js/css时，如果我删除package-lock.json，就不会有任何问题。|4358715|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%25+building+0/1+modules+1+active+...|4358716|entityMap^0|0|0|1|B|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|12|8|@$F|13|G|14|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|15|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|16|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|17|8|@]|9|@]|A|$]]|$1|P|3|Q|5|R|7|18|8|@]|9|@]|A|$S|T]]|$1|U|3|V|5|6|7|19|8|@]|9|@]|A|$]]|$1|W|3|X|5|R|7|1A|8|@]|9|@]|A|$S|T]]|$1|Y|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|Z|$]]

My use of npm is to generate minified/uglified css/js and to generate the javascript needed in pages served by a django application. 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. 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. 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. I don't use mongodb or other such applications that are traditionally thin client.

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. Version control of node and npm are done manually on each server, but I am careful that they are the same. 

When <code>npm install</code> 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. That is
you can't deploy because the pull will overwrite the changes that have been made to 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. Now if this indicates that slightly different versions have been installed in node_modules, once again that has never caused me problems.

If node_modules is not on your repo (and it should not be), then package-lock.json should be ignored.

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:

<pre><code>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'
</code></pre>

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

<pre><code>jason@localhost:introcart_wagtail$ rm package-lock.json 
jason@localhost:introcart_wagtail$ npm run dev

&gt; introcart@1.0.0 dev /home/jason/webapps/introcart_devtools/introcart_wagtail
&gt; NODE_ENV=development webpack --progress --colors --watch --mode=development

 10% building 0/1 modules 1 active ...
</code></pre>

blocks|key|4358817|text|将package-lock.json提交到源代码版本控制意味着项目将使用特定版本的依赖项，该依赖项可能与package.json中定义的依赖项匹配，也可能不匹配。虽然依赖项有一个特定的版本，但如您所见，没有任何Caret+(%5E)和Tilde+(~)，这意味着依赖项不会更新到最新版本。npm+install将获得与我们当前版本的Angular所需的相同版本。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4358818|注意:如果我在CI期间向要更新的依赖项添加了任何Caret+(%5E)和Tilde+(~)，强烈建议使用package-lock.json提交它。|4358819|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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. 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.
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.

<a href="http://blog.npmjs.org/post/161081169345/v500" rel="noreferrer">npm 5 was released today</a> and one of the new features include deterministic installs with the creation of a <code>package-lock.json</code> file.

Is this file supposed to be kept in source control?

I'm assuming it's similar to <a href="https://stackoverflow.com/questions/39990017/should-i-commit-the-yarn-lock-file-and-what-is-it-for"><code>yarn.lock</code></a> and <a href="https://stackoverflow.com/questions/12896780/should-composer-lock-be-committed-to-version-control"><code>composer.lock</code></a>, both of which are supposed to be kept in source control.

Do I commit the package-lock.json file created by npm 5?

服务器

GitHub

和其中一个新功能包括创建package-lock.json文件时的确定性安装。这个文件应该保存在源代码管理中吗？我假设它类似于和，这两者都应该保持在源代码控制中。

问我要提交npm 5创建的package-lock.json文件吗？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问我要提交npm 5创建的package-lock.json文件吗？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问我要提交npm 5创建的package-lock.json文件吗？
EN