The lockfile should not be updated if it is detected that the proposed changes are equal to the existing lockfile. However, at present it updates the file with a new timestamp, leading to diff'ing noise on inconsequential changes
How will this benefit other users?
When running dependencyLockWrite the only updated files will be files that have actually had dependency changes, and not just because the timestamp field has been altered
Is there a workaround that can do this now?
Without this enhancement i run sbt dependencyLockCheck || sbt dependencyLockWrite so that the write is only run if there is a detected difference in the check. However, if I blindly run sbt dependencyLockWrite on an sbt multi project I get a bunch of timestamp only diffs on build.sbt.lock files with no other relevant change
Will this require a lock file change?
No change to lock file format at all
Other details
We are working on a private repo so cannot link publicly, but we have effectively a mono-repo with a dozen or so sbt sub-projects in it, and we use sbt-dependency-lock to manage changes to dependencies, particularly transitive dependency changes.
What are you suggesting?
The lockfile should not be updated if it is detected that the proposed changes are equal to the existing lockfile. However, at present it updates the file with a new timestamp, leading to diff'ing noise on inconsequential changes
How will this benefit other users?
When running
dependencyLockWritethe only updated files will be files that have actually had dependency changes, and not just because the timestamp field has been alteredIs there a workaround that can do this now?
Without this enhancement i run
sbt dependencyLockCheck || sbt dependencyLockWriteso that the write is only run if there is a detected difference in the check. However, if I blindly runsbt dependencyLockWriteon an sbt multi project I get a bunch of timestamp only diffs on build.sbt.lock files with no other relevant changeWill this require a lock file change?
No change to lock file format at all
Other details
We are working on a private repo so cannot link publicly, but we have effectively a mono-repo with a dozen or so sbt sub-projects in it, and we use
sbt-dependency-lockto manage changes to dependencies, particularly transitive dependency changes.