Should project.lock.json file be checked into source control? (ASP.NET Core 1.0)

Question

Using ASP.NET Core 1.0, is it best practice to check in the project.lock.json file into source control?

Answer 1

Short answer: No, project.lock.file should not be checked into source control - you should configure the version control system to ignore it (i.e. add it to .gitignore if you're using git).

Long answer: The project.lock.json contains a snapshot of project's whole dependency tree - not just packages listed in "dependencies" sections, but also all resolved dependencies of those dependencies, and so on. But it is not like ruby's Gemfile.lock. Unlike Gemfile.lock, project.lock.json doesn't tell dotnet restore which exact versions of packages should be restored - it simply gets overwritten. As such, it should be treated like a cache file and never be checked into source control.

If you check it into version control, then most probably on other machine:

• dotnet will think that all packages are restored, but in fact some packages might be missing and the build will fail, without hinting the developer to run dotnet restore
• project.lock.json will be overwritten during dotnet restore and in most cases will be different than the version stored in source control. So it will be modified in almost every commit
• project.lock.json will cause conflicts during merge

Answer 2

Actually you do want to commit your project.lock.json in git sometimes.

Checking your project json

For the exact reasons that, it shows you the dependencies you have used. Say:

1. Me as a developer works on an application, i hate every time updating packages so i add a package dependency to nuget package X = 1.*
2. I restore package i get version 1.2.4
3. The package maker just made a very stupid mistake, he broke something while just trying to make a fix and release 1.2.5
4. Person 2 checks out (or even worse release build kicks in).
5. Person 2 restores and gets version 1.2.5
6. Person 2 runs your application and find the application is broken.
7. Person 2 starts debugging and thinks there must be a bug in the software.

At this step 7 Person 2 could have seen in git that his lock file was changed and a newer version of a library has been downloaded, Which has not been tested by any of the other developers!

Downsides

Downsides of checking in this file is you might get allot of merge conflicts on continues updates of packages.

Alternative solution

Use only hard version dependencies (this is quite hard though for nuget). And only manually update to newer version once in a while.

Downsides

• This doesn't work if you build a library for other people to use, since you pin them to a certain version of your dependencies.
• Dependencies of dependencies still get resolved automatically so if you don't specify them yourself you can't guarantee there version on dotnet restore

Conclusion

If you want to avoid 'Works on my machine' quotes and the hell of constantly manually updating to newer version: Checking the project.lock.json.

And also build a CI/Release build check to test if this file wasn't changed compared to git, before you release (If your software is very critical)!

If this is not a problem and also automatically updating (to a potentially broken package) is not a big problem, you might not want to commit your project.lock.json.