我是否提交包——锁定。 由 npm 5创建的 json 文件?

npm 5 was released today and one of the new features include deterministic installs with the creation of a package-lock.json file.

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.

转载于:https://stackoverflow.com/questions/44206782/do-i-commit-the-package-lock-json-file-created-by-npm-5

csdnceshi50
三生石@ Depends on the project. github.com/npm/npm/issues/20603
2 年多之前 回复
csdnceshi58
Didn"t forge A file can't help produce a deterministic install if it doesn't exist.
大约 3 年之前 回复
csdnceshi59
ℙℕℤℝ Short answer: yes. One comment: when package-lock.json changes you can make a commit of just that change, separate from other source changes. This makes git log easier to deal with.
大约 3 年之前 回复

8个回答

Yes, package-lock.json is intended to be checked into source control. If you're using npm 5, you may see this on the command line: created a lockfile as package-lock.json. You should commit this file. According to npm help package-lock.json:

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 "time-travel" 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.

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. It shares a format with npm-shrinkwrap.json(5), which is essentially the same file, but allows publication. This is not recommended unless deploying a CLI tool or otherwise using the publication process for producing production packages.

If both package-lock.json and npm-shrinkwrap.json are present in the root of a package, package-lock.json will be completely ignored.

csdnceshi57
perhaps? The reasoning in that Yarn blog post is very short sighted and should not be relied on. It only considers the case of a bug being introduced in a dependency, which will be fixed in an upcoming release without requiring changes in your library. Unfortunately in real life not all dependency problems are due to upstream bugs that go away on their own without any action required.
2 年多之前 回复
csdnceshi60
℡Wang Yan Every time I run a npm install. The value in integrity fields change even the version of the packages are the save. Any idea how does this happen?
2 年多之前 回复
csdnceshi61
derek5. Yes, you can include it, but if resolved field is used, add relative URLs instead of referencing npmjs.org to support internal repositories behind a firewall.
2 年多之前 回复
csdnceshi63
elliott.david I don't do it. I delete this file each time it's generated. If there's any problem, I delete the node_modules/ directory and run npm install again. I even change every version to * in the dependencies and devDependencies. My attitude is if there's problem, solve it. I'd rather use all latest version. Anything that is outdated makes me feel sick.
2 年多之前 回复
csdnceshi73
喵-见缝插针 Some developers prefer not to commit lock files for their library packages, because they believe they can catch and fix issues with dependencies before users can. This is a flawed argument as pointed out in the post "Lockfiles should be committed on all projects". Not committing your lock file also makes it more difficult for new users to contribute to your library.
2 年多之前 回复
weixin_41568131
10.24 Side question would be: "Should we flag it as binary in our .gitattributes so that changes are not looked at?" EDIT: Actually found part of the answer HERE
2 年多之前 回复
csdnceshi59
ℙℕℤℝ If I understand correctly what this all means... since the file is ignored when you publish your package... this 'reproducability' comes at a steep price. Namely... while I have something reprodicble for myself and my co-developers working from checked-out source. The people installing my publsihed package may get something completely different. So... basically me and my fellow developers may not be noticing if dependency changes are breaking stuff, but our users installing the published package will.
2 年多之前 回复
csdnceshi55
~Onlooker I have since switched to Yarn. Has a few minor non-blocking incompatibilities but it's terribly fast in comparison to npm
大约 3 年之前 回复
csdnceshi68
local-host same here, not to mention that it had a tendency to occupy the first several screen-heights of any diff in code review tools. A massive pain in the arse for next to no benefit as far as I can see at the moment.
大约 3 年之前 回复
csdnceshi55
~Onlooker Personally I've now had to resort to adding package-lock.json to my .gitignore... it was causing me far more problems than solving them. It always conflicts when we merge or rebase, and when a merge results in a package-lock.json being corrupted on the CI server, it's just a pain to have to stay fixing it.
大约 3 年之前 回复
weixin_41568127
?yb? It doesn't seem like the question of lockfiles for libraries has consensus. For instance, James Kyle recommends committing lockfiles for libraries/packages to make contributing easier.
大约 3 年之前 回复
csdnceshi64
游.程 that's a new question to ask, not a comment. Also, npm link.
大约 3 年之前 回复
csdnceshi64
游.程 maybe a good idea!
大约 3 年之前 回复
csdnceshi78
程序go I'm developing two packages: a library and an example app using the library. I want to make tons of changes to the library while writing the example app. I'm deploying the example app on Heroku. New NPM wants to remeber the commit hash I was using when typed npm install github:<my_library>. When I publish it on Heroku, it uses old version. I have to type npm install at the example app folder each time after commiting the library on GitHub. Of course, very often I forget to do that. How to tell NPM to not lock a GitHub repo?
大约 3 年之前 回复
csdnceshi56
lrony* I think we might want to consider adding the caveat about packages vs. apps to this answer -- what do you think?
大约 3 年之前 回复
csdnceshi64
游.程 Another thing is, package-lock.json is ignored for publishing on NPM, so if a developer uses it for a library dev, then they are minimizing the chance that they will catch a regression from an updated dependency version, and therefore will pass that bug onto end users. For this reason, not using a lock file for library dev increases the chance of shipping less bugs.
3 年多之前 回复
weixin_41568127
?yb? Sindre Sorhus recommends using "Lockfiles for apps, but not for packages."
3 年多之前 回复
csdnceshi64
游.程 But is it intended to be checked in to source control for top-level apps? Or also checked into source control for library packages?
3 年多之前 回复
weixin_41568184
叼花硬汉 The key word is "shouldn't need to be" - but in practice people don't follow semver perfectly. That's why you can use package-lock.json and package.json together to make it easy to update packages but still making sure every developer and every deployed application is using the same dependency tree.
3 年多之前 回复
csdnceshi65
larry*wei In what kind of projects is it actually helpful to commit the file? The whole point of semver and package.json is that updated compatible dependencies shouldn't need to be noted.
3 年多之前 回复
csdnceshi53
Lotus@ Excellent find, thank you! I can't wait to try npm 5 for my projects in the upcoming week, have been reading great things about it.
3 年多之前 回复

You can check the npm's official docs.

Yes, you can commit this file. 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.

csdnceshi67
bug^君 Won't an install always update node_modules, and therefore update package-lock.json?
2 年多之前 回复

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.

csdnceshi79
python小菜 You cannot publish the package-lock.json file: docs.npmjs.com/files/package-lock.json
2 年多之前 回复
weixin_41568184
叼花硬汉 As I understand it, you're partially correct. Publishing this file to npm is not up for debate. You can't publish it.
2 年多之前 回复
csdnceshi73
喵-见缝插针 Any advice regarding the package-lock.json file when working on a SCM system with trunks and branching? I'm making some changes on a branch that need to be merged to trunk... do I now have to (somehow) resolve conflicts between the two package-lock.json files? This feels painful.
2 年多之前 回复
csdnceshi60
℡Wang Yan I usually keep package installations separate from other work. I never need to diff a commit like "Installed chai and mocha", because I already know what changed.
接近 3 年之前 回复
csdnceshi78
程序go by noise I mean that the commits with package-lock.json can have so many lines of node package versions, that any other work in that commit becomes hidden.
接近 3 年之前 回复
weixin_41568126
乱世@小熊 Could you tell me more about this to me "lot of noise to our diffs"? I think I have the idea but I prefer to be sure.
接近 3 年之前 回复
csdnceshi58
Didn"t forge it's fair to debate whether it should be checked into your source code repository, but publishing this file to npm is not really up for debate - you must include either your package-lock.json or your shrinkwrap file into your npm registry. if you do not, your published package will be subject to unpinned changes of dependencies of your 1st generation dependencies. you won't notice this to be a problem until one of those 2nd+ generation dependencies publishes a breaking change, and your published package becomes mysteriously broken. this package-lock.json file was created to solve that problem.
大约 3 年之前 回复

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

git diff -- . ':(exclude)*package-lock.json'

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'"

I don't commit this file in my projects. What's the point ?

  1. It's generated
  2. It's the cause of a SHA1 code integrity err in gitlab with gitlab-ci.yml builds

Though it's true that i never use ^ in my package.json for libs because I had bad experiences with it :)

Regards.

csdnceshi60
℡Wang Yan I wish this could be expounded more from within npm docs - It would be useful to have an outline of what specifically you lose by not committing package-lock.json. Some repos may not require the benefits that come from having it, and may prefer to have no auto-generated content in source.
大约 2 年之前 回复

Yes, the best practice is to check in

I agree that it will cause a lot of noise or conflict when seeing the diff. But the benefits are:

  1. guarantee exact same version of every package. This part is the most important when building in different environments at different times. You may use ^1.2.3 in your package.json, but how can u 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? Well, package-lock.json will ensure that. (With the help of npm ci which installs packages based on lock file)
  2. it improves the installation process.
  3. it helps with new audit feature npm audit fix (I think the audit feature is from npm version 6).
csdnceshi70
笑故挽风 As far as I know, never using semver (which npm devs dont understand anyway) should yield the same behavior as having a lockfile at least in 99% of cases. My own experience is that semver fuckups happen mostly with primary packages (direct dependencies, crappy jquery datepickers, etc). My personal experience with npm has been that lock files were noise forever. I hope this wisdom is unchanged with recent versions.
2 年多之前 回复

Disable package-lock.json globally

type the following in your terminal:

npm config set package-lock false

this really work for me like magic

Note: First of all, I was not able to make the below suggested solution work but I feel that with more knowledge about subject we can make it work. Let me know if that helped you or my understanding about npm-merge-driver is wrong.

As said by many here it will cause a lot of noise or conflict, in that case run:

npx npm-merge-driver install -g

And

npx npm-merge-driver install
$ git merge my-conflicting-branch
npm WARN conflict A git conflict was detected in package-lock.json. Attempting to auto-resolve.

added 1 package in 0.077s
Auto-merging package-lock.json
Merge made by the 'recursive' strategy.
 package-lock.json | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
$ git status
<clean>

Check more on docs here: https://www.npmjs.com/package/npm-merge-driver

Csdn user default icon
上传中...
上传图片
插入图片
抄袭、复制答案,以达到刷声望分或其他目的的行为,在CSDN问答是严格禁止的,一经发现立刻封号。是时候展现真正的技术了!
立即提问
相关内容推荐