Mixing build.sbt with project *.scala files: should all be unified in build.sbt?

Question

Using SBT 0.13.13, our build definition is inherited from an older project. Currently there are a build.sbt and some project/*.scala files. These scala files follow the same pattern. Here is an example:

import sbt._
import sbt.Keys._

object Docs {
  lazy val docTask = TaskKey[Unit]("docPackage", "Generate Scaladoc")

  lazy val settings = Seq(
    docTask := {
      val docs = (doc in Compile).value
      IO.copyDirectory(docs, new java.io.File("src/main/resources/myapp-scaladoc"), overwrite = true)
    },

    docTask := (docTask.dependsOn(doc in Compile)).value
  )
}

Appendix: .scala build definition says

In the previous versions of sbt, .scala was the only way to create multi-project build definition

Question : I suppose this mean the use of separate project/*.scala files is discouraged. If so, is it OK to move the code of these *.scala file and put them all in build.sbt?

Answer 1

There is little functional difference between having code in project/ and code in build.sbt .

The advantage to putting code in a .scala file in project/ is that all symbols in it are imported into the namespace of all build.sbt files in all subprojects of your build. This means that helper methods, constants, plugins, or other Scala code can live in a single location, but be called from anywhere.

Ultimately, whether to use this features comes down to whether you want shared items configured in a single location, or in multiple locations.

If you prefer to have your project settings configured entirely in separate build.sbt files in their subproject directories, putting shared settings in the project/ folder is the way to do that.

If you're OK with having shared settings configured in the root build.sbt file (or if you don't use any subproject build.sbt files), you can consolidate all of your shared configuration into it.