Glad you asked! It's an easy mistake to make.
That would be a bad practice. It would mean that the lockfile completely loses of it's original purpose.
If you do that in a project/lib that you alone maintain perhaps that's not the end of the world (still not ideal IMO though), but as part of a team it would completely make the lockfile redundant.
So if you have the same dependencies in your different environments (prod, dev, test, etc.) and your merge causes a package lock file conflict, it would
be better to manually edit the package lock file?
I think I need to look more into the value and purpose of the lock file.
No. In no circumstance it would be appropriate to manually edit a lock file. Generally speaking if you need to "fix" a lock file. It's better to use the package manager built-in tooling for it. For example, yarn supports automatic resolution of conflict merge issues that fix the lock file.
If that doesn't help. You can update the lock file by running the install/remove commands using the package manager so that it takes care of updating the lock file for you.
Regardless of this, during CI builds you want to maintain reproducible builds and be strict on what packages you install.
Maybe it wasn't very clear in the post but to provide this as an example:
package.json defines dependency myCoolModule version 1.2.3
lockfile has myCoolModule version 0.0.1
At this point, it doesn't really matter how (1) and (2) are different (whether merge conflict issue, or someone forgot to sync the package.json with the lock file)
if your CI server runs npm install then it would detect that the package lock is out of date and both update it (which means it modifies the git copy it cloned, bad to begin with), and brings in 1.2.3 which is what the package.json defined, but not the lock file. Therefore, making the lock file useless.
Instead, you'd want in your CI to run npm ci which reads the lock file as a source of truth, and will bring you myCoolModule version 0.0.1. If it breaks your tests - all the better, it means that the build stopped you from shipping something you didn't expect.
Glad you asked! It's an easy mistake to make.
That would be a bad practice. It would mean that the lockfile completely loses of it's original purpose.
If you do that in a project/lib that you alone maintain perhaps that's not the end of the world (still not ideal IMO though), but as part of a team it would completely make the lockfile redundant.
So if you have the same dependencies in your different environments (prod, dev, test, etc.) and your merge causes a package lock file conflict, it would
be better to manually edit the package lock file?
I think I need to look more into the value and purpose of the lock file.
No. In no circumstance it would be appropriate to manually edit a lock file. Generally speaking if you need to "fix" a lock file. It's better to use the package manager built-in tooling for it. For example, yarn supports automatic resolution of conflict merge issues that fix the lock file.
If that doesn't help. You can update the lock file by running the install/remove commands using the package manager so that it takes care of updating the lock file for you.
Regardless of this, during CI builds you want to maintain reproducible builds and be strict on what packages you install.
Maybe it wasn't very clear in the post but to provide this as an example:
At this point, it doesn't really matter how (1) and (2) are different (whether merge conflict issue, or someone forgot to sync the package.json with the lock file)
npm installthen it would detect that the package lock is out of date and both update it (which means it modifies the git copy it cloned, bad to begin with), and brings in 1.2.3 which is what the package.json defined, but not the lock file. Therefore, making the lock file useless.Instead, you'd want in your CI to run
npm ciwhich reads the lock file as a source of truth, and will bring you myCoolModule version 0.0.1. If it breaks your tests - all the better, it means that the build stopped you from shipping something you didn't expect.Hope it's a bit clearer :-)
I see. Thanks for the reply.