mudasobwa
I want to share some concerns about storing mix.lock file in VCS for libraries. The current version of Library Guidelines page has zero mentions of mix.lock and the established community practice is to indeed version control mix.lock.
Which is meaningless and might be even harmful in some scenarios.
Consider the library A that depends on another library B. B occasionally introduces a breaking change in the minor updates. Even if A library has nightly builds turned on, it continues to be green because in mix.lock there is a previous version of B. All the projects, depending on A get broken, because they ignore A’s mix.lock.
Without mix.lock in the VCS, A library author would have been informed a night after B upgrade. With mix.lock file in VCS, they will be informed by a tornado of issues from A users days after.
A less exotic case might be also taken into account: A depends on B and C, then B and C start conflicting on D at some point, but A nightly builds are still all green, because there is mix.lock in VCS and A is never tried to compile against modern versions of B, C, and D.
This is all not expected in our great self-organized ecosystem, but things happen. Currently, I personally switch nightly build on and remove mix.lock from VCS. It makes me think I will, at least, be notified about issues with the latest dependencies consistency the very next night.
I think removing mix.lock from VCS for libraries is a good practice in any case and I think we might enforce/suggest it via Guidelines I linked above.
Thoughts? /cc @josevalim
Where Next?
Trending in Discussions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
Producing high quality Elixir screencasts since 2017.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
josevalim
The benefit of
mix.lockis making builds reproducible. You don’t want contributors to jump into a library and then become unable to write a patch because they can’t get their tests to pass anyway.If the goal is to catch bugs, then I recommend having additional builds on CI that remove the lock file before running. Then you get the best of both words.
mudasobwa
Eh. Does not that mean that projects using that library cannot use that library because of, well, above?
Or, even worse, they can get it to compile, but tests were red in this env, if they were ever attempted?
benwilson512
If a new version of library A’s dependency B breaks A, and I’m some contributor trying to fix some other, unrelated bug in A, how does it benefit me or the owner or the owner of A that I’m stuck and can’t move forward?
If that were the only way to know about breaking updates to B then sure, but as Jose noted, this is solved with a CI setup that simply unlocks everything before running tests. Perhaps that suggestion is what is missing from the guides?
mudasobwa
Seems like a best solution, yes. I would strongly appreciate putting it there to alarm future library owners, yes. Shall I provide a PR?
josevalim
A PR that recommends checking it under version control and running a separate build without it would be welcome, yes.
mudasobwa
On it.
dbern
FWIW, I’ve found the same issue, and in CI I’ve started deleting the mix.lock before getting deps and running tests.
to removing it for libraries; regardless, I’m hopeful that this isn’t a common problem.
fmcgeough
mix deps.get has a command line option
--check-locked. This was added in mix version 15.0.0. The doc says “raises if there are pending changes to the lockfile”. CI should use this so that if a change occurs where mix needs to modify the mix.lock file it can raise an exception. I recommend 1) check in the mix.lock file; 2) add that option to your CI builds. This ensures that what is built in CI is what was built on dev boxes and you’d be notified of discrepancies.mix deps.get options
lud
If I understand correctly this makes your CI fail if there are possible updates to the dependencies, even if your CI ran otherwise fine with the latest updates (by deleting
mix.lockin CI)?Or do you not delete
mix.lockand callmix deps.update --allin CI.Because if you check in the
mix.lockand just runmix deps.get --check-lockedin CI then how can it fail?Edit:
Well actually I don’t uderstant what raises if there are pending changes to the lockfile means. I though it was checking on git status but it seems that it’s supposed to do something else.
benwilson512
Let’s say someone makes a change to mix.exs to switch from version 1 to version 2 for a dependency. The lock file is now “out of date” as the version in the lock file is now incompatible with what’s in mix.exs.
In development that’s fine, and you just get deps to write a new lock file. but what if you developer forgets, and commits the new mix.exs version without pulling deps and writing a new lock file? This is the value of the option. In the CI you want this to raise instead of silently writing a lock file.