Option to have build-wide lock file

[cornerman]

Refering to issue #12, I would actually like an option for a build-wide lockfile. Working with multiple projects and js/jvm builds, the current approach yields a lot of lock files, which are difficult to overview. Also, for my use-case, a build-wide lockfile just makes more sense, as all of the projects will be packaged into a fat jar anyway.

Any way to make this a configuration option? Can I maybe help?

[htmldoug]

Sounds like you only care about the project that generates the fat jar. What if you disablePlugins(SbtLockPlugin) in the other non-fat jar projects?

[cornerman]

@htmldoug thanks for the suggestion, but I am not sure whether this would work for me. If there is only one assembly project, this is fine. But in my case, I have a scala-js and jvm project both depending on some shared scala projects. When building, I would like to have all dependencies in both projects locked to one version. With sbt-lock only activated in the scala-js and jvm project, I might still get different dependency resolutions, right?

[htmldoug]

Different versions across the projects would be possible, yes. You're right, that's a little awkward.

I agree that this would have to be implemented an additional option. I also have a use-case for #12 for supporting different versions of play-json in different projects within the same build. Hypothetically, what would a per-build lock file determine to be the version in this case?

sbtLockScope in ThisBuild := SbtLockScope.PerBuild // imaginary example setting
val json26 = project.settings(libraryDependencies += org %% "play-json"  % "2.6.0")
val json27 = project.settings(libraryDependencies += org %% "play-json"  % "2.7.0")

/lock.sbt

dependencyOverrides += org %% "play-json"  % "???" // generated

Of course, this isn't an intended use-case for per-build scope, but I could imagine the situation happening accidentally for transitive dependencies. The behavior should be well-defined.

[cornerman]

Very good point, there should be a well-defined behaviour! I believe, we should probably adhere to the conflict mangement already defined in sbt: By default, the latest revision is selected. This can be changed by setting conflictManager, which has type ConflictManager. (https://www.scala-sbt.org/1.x/docs/Library-Management.html#Conflict+Management).

So, by default, your example should yield version 2.7.0 for play-json. And you could change that behaviour and error out or do something different. With transitive dependencies this is already happening within one project, so maybe we can just resolve these dependencies accordingly via sbt?