Checking in Lockfiles

In the context of library development you can choose to check in a lockfile or not. With an end of the line binary application you should always just check in the lockfile, choose the versions to build with. But which way should you go for a library?

For a consumer of a library, it really doesn’t matter all that much. They will build their application with versions which fit the constraints of the library. So the choice to check in the lockfile or not is just whatever makes the maintainer’s life easier.

Checking in a file gives you a paper trail. At this hash we built with these versions. And this is probably the biggest differentiator. Not checking in a lockfile leaves you with the same constraints, but it is possible that those get resolved differently at a later date. Strategies could change, or dependency updates.

The downside to checking in a lockfile is that it’s another file to manage. Every time a dependency is tweaked it should be updated. I believe this is CI-enforceable at least though, cargo has a --locked flag which will fail a command if Cargo.toml has changed in a way which would require the lockfile to be updated.

The lockfile management gets a little more complicated too if you want to test a window of dependencies (which I think is a good idea). You have to check in your “minimal” and “recent” dependencies. This can all be scripted away though and handled by a justfile (or build tool of choice).

So reasons to not? Beyond less maintenance, it probably exposes you to upstream issues sooner. If your CI uses entirely locked dependencies, you won’t see that upgrade with breaking changes until you modify your own lockfile in some way which triggers an upgrade to that dependency. Maybe that can be iron’d out with a weekly cron job or something which pulls in the recent versions. Perhaps the use case for that noisy dependabot on github?