This is important because it guarantees that every developer in the team will have the same version on their machine, and it is equally important for CI/CD.
So if 4.2.1 is the latest version at the moment of your install, this version will be written to package-lock and will, from there on, always be installed.Įven if newer versions come out that are theoretically compatible with it. Upon installing, it will "lock" you in on the version that you just installed. This is where package-lock.json comes into play. Which means "compatible with version, according to semver".Įnter, for example, lodash as the package and ^4.2.1 as version,Īnd you will see that you can get anything from 4.2.1 to 4.17.20 (the latest version)
#GIT ACCEPT ALL INCOMING CHANGES VSCODE INSTALL#
When you install a dependency for the first time, it is usually automatically added to your dependencies or devDependencies with ^version, Why you should never delete package-lock.json The conflicts in package.json are usually easily solved (if there even are any), so I think it is tempting to just delete package-lock.json and run npm install.Īfter all, this will give you a brand new package-lock.json, which you can happily commit. So here you are, updating your PR with the base branch, and git shows you this huge amount of conflicts in package-lock.json.
The result of package-lock then changes, and whoever gets their PR merged to main first is the lucky one who avoided those conflicts. It usually happens when two branches add or update a dependency. One thing that can be costly when done wrong is solving conflicts in generated files, like package-lock.json. I wish I wouldn't spend as much time solving git conflicts as I currently am.
0 kommentar(er)
