{"action":"created","issue":{"url":"https://api.github.com/repos/aspnet/dnx/issues/2332","labels_url":"https://api.github.com/repos/aspnet/dnx/issues/2332/labels{/name}","comments_url":"https://api.github.com/repos/aspnet/dnx/issues/2332/comments","events_url":"https://api.github.com/repos/aspnet/dnx/issues/2332/events","html_url":"https://github.com/aspnet/dnx/issues/2332","id":96998619,"number":2332,"title":"Split project.lock.json into *.lock.json and *.cache.json","user":{"login":"Mpdreamz","id":245275,"avatar_url":"https://avatars.githubusercontent.com/u/245275?v=3","gravatar_id":"","url":"https://api.github.com/users/Mpdreamz","html_url":"https://github.com/Mpdreamz","followers_url":"https://api.github.com/users/Mpdreamz/followers","following_url":"https://api.github.com/users/Mpdreamz/following{/other_user}","gists_url":"https://api.github.com/users/Mpdreamz/gists{/gist_id}","starred_url":"https://api.github.com/users/Mpdreamz/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Mpdreamz/subscriptions","organizations_url":"https://api.github.com/users/Mpdreamz/orgs","repos_url":"https://api.github.com/users/Mpdreamz/repos","events_url":"https://api.github.com/users/Mpdreamz/events{/privacy}","received_events_url":"https://api.github.com/users/Mpdreamz/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-07-24T08:15:45Z","updated_at":"2015-07-24T19:53:53Z","closed_at":null,"body":"I've read [this gist on checking in project.lock files]( https://gist.github.com/brunomlopes/97b433593d61e5481788) a couple times over and I really feel the current locking design feels optimized for the wrong scenario: finding breaking changes in moving targets.  Whereas the more important default scenario should be repeatable builds.\r\n\r\nTo the best of my understanding the current project.json.lock now serves two purposes, caching the files in play for compilation and optionally locking dependencies  using `--lock`. \r\n\r\nThis results in a bit of a operational kerfuffle. When do i need to restore using `--lock` ? Do I need to unignore lock files in release tags, and if so is this not important on dev branch too? if I branch of those tags should i remove the lock file on the first change? \r\n\r\nWhat if locking is simply the norm just as it is in Paket?\r\n\r\nRestore writes a very minimal `project.lock.json` (look at [Paket for an example](http://fsprojects.github.io/Paket/lock-file.html)) if not present that you should **always** commit (eradicating both `--lock` and `lock:false` confusion).\r\n\r\nWhen dnx runs the app for the first time it will generate a `.project.cache.json` which you should **never** commit. \r\n\r\nIf folks want to check fast moving targets on a CI server they could do `dnu restore --latest` on the CI servers explicitly.\r\n\r\n* `dnu restore --latest` updates all `*` dependencies\r\n* `dnu restore --update` updates all dependencies to latest\r\n* `dnu restore --outdated` simply reports on packages that are outdated\r\n\r\nTo be fair [the wiki](https://github.com/aspnet/Home/wiki/Lock-file) does not dictate not checking `project.lock.jso`n files but does leave it up in the air without a consistent story.\r\n\r\nEven if we do not make locking the norm a split will really help those who do choose to commit the lock file to not be faced with merge conflicts in the cached files section of this lock file."},"comment":{"url":"https://api.github.com/repos/aspnet/dnx/issues/comments/124685899","html_url":"https://github.com/aspnet/dnx/issues/2332#issuecomment-124685899","issue_url":"https://api.github.com/repos/aspnet/dnx/issues/2332","id":124685899,"user":{"login":"anurse","id":7574,"avatar_url":"https://avatars.githubusercontent.com/u/7574?v=3","gravatar_id":"","url":"https://api.github.com/users/anurse","html_url":"https://github.com/anurse","followers_url":"https://api.github.com/users/anurse/followers","following_url":"https://api.github.com/users/anurse/following{/other_user}","gists_url":"https://api.github.com/users/anurse/gists{/gist_id}","starred_url":"https://api.github.com/users/anurse/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/anurse/subscriptions","organizations_url":"https://api.github.com/users/anurse/orgs","repos_url":"https://api.github.com/users/anurse/repos","events_url":"https://api.github.com/users/anurse/events{/privacy}","received_events_url":"https://api.github.com/users/anurse/received_events","type":"User","site_admin":false},"created_at":"2015-07-24T19:53:53Z","updated_at":"2015-07-24T19:53:53Z","body":"Note: We need to be extremely careful what we do here now that NuGet 3 and MSBuild for UWP apps are using `project.json` and `project.lock.json`"}}