Should the lock files be on git?

Hello awesome readers!

Today, let's dive into a topic that's close to the heart of every developer who's battled with the "But it works on my machine!" issue. Yes, we're talking about manifest files - those little files that often have .lock in their name, such as yarn.lock, gemfile.lock, or package-lock.json. If you've ever wondered whether you should be keeping these files under version control or just .gitignore them, then keep reading!

If you’ve read this far, you’re probably a DeployBot user and familiar with version control systems, CI/CD, and other related topics. If not, we’ve compiled several beginner’s guides: Laravel, Digital Ocean, Ruby on Rails, Docker, Craft CMS, Ghost CMS, Google Web Starter Kit, Grunt or Gulp, Slack, Python, Heroku and many more.

Learn how to get started with DeployBot here.

What are these .lock files anyway?

Before we get into the why, let's address the what. These .lock files are automatically generated by package managers like Yarn, Bundler, or NPM. Their primary role is to lock down the exact versions of the dependencies your project uses. This means that if you install a package today and then again in a month, the manifest will ensure that you're using the exact same version, rather than potentially a newer version that might introduce breaking changes.

So, why should we version control them?

  1. Consistency Across Environments: The primary reason to keep these files under version control is to ensure that all environments (your local machine, your teammates' machines, staging, production, etc.) are using the same versions of all dependencies. This minimizes the "works on my machine" syndrome and ensures that if it works in one place, it should work everywhere.
  2. Faster Installation: With a .lock file, your package manager doesn’t need to resolve versions or figure out the dependency tree. It already knows the exact versions to install. This can lead to significantly faster installation times, especially in larger projects.
  3. Historical Reference: Imagine you discover a bug in your application that wasn't there two weeks ago. By keeping your manifest file under version control, you can easily reference the exact state of your dependencies from two weeks ago and pinpoint if a dependency update is causing the bug.
  4. Collaboration and Conflict Prevention: When you have multiple people working on a project and adding or updating dependencies, the manifest file can help prevent conflicts and ensure everyone is on the same page.
  5. Protect Against Unintended Upgrades: Even if you specify a version range for a package in your main dependency file, updates can sneak in if they satisfy the range. The .lock file prevents these surprise upgrades by specifying the exact versions.

Any downsides?

There's a minor argument that these files can make your repository bulky, especially for projects with lots of dependencies. However, the benefits heavily outweigh this minor inconvenience. And let's be honest, disk space is cheap, but developer time and sanity are not!

Wrapping Up

So, if you've been on the fence about whether to commit your .lock files to version control, we hope this post has made things clear. They play a crucial role in ensuring consistency, speeding up installs, and making collaborative work smoother.

Remember, when it comes to software development, predictability is golden. And manifest files like yarn.lock, gemfile.lock, or package-lock.json are your golden ticket to a smoother, more predictable development experience.

Happy coding! 🚀

Comments