Sbt is a build tool that uses a state-command design where commands make changes to the build state. It operates incrementally by evaluating tasks only when needed. Key concepts include applicative composition which sequences tasks in dependency order, and "happens before" which defines task evaluation order. Future updates may include build linting, caching, and server support for improved IDE integration.

1. sbt
core concepts and updates
Eugene Yokota (@eed3si9n)

2. goal:
gain better intuition about sbt

3. sbt by example

4.
build tool
• "automates repeatable tasks"
— Build Systems à la Carte
Mokhov, Mitchell, Jones

5. a casually functional
build tool

6. State

7. State
1. build structure
2. your disk

8. Command
• State State

9. Command
• State State
• processed sequentially
• low-level construct; avoid making custom commands

10. examples of command
commands
help, tasks
projects, project hello
set name := "foo"
<command1>; <command2>
++ 2.13.0, ++ 2.13.0!, +<command>
shell command
act command

11. act command
• lifts tasks and settings into a command

12. which state is it changing?
commands changes
help, tasks no changes
projects, project hello build structure
set name := "foo" build structure
<command1>; <command2> both
++ 2.13.0, ++ 2.13.0!, +<command> both
act command disk

13. why State + Command?

14. why State + Command?
• predictable checkpoint
• building block for interactiveness:
"automates repeatable tasks"

15. interactive
sbt> testOnly foo.bar
command
logs
sbt shell
effects

16. about time

19. distributed events
event a
event b
"happens before"
process p

20. distributed events
event a
event b
"happens before"
process p process q

21. distributed events
• a → b (a happens before b)
• a ↛ b (a does not happen before b)
• 2 distinct events a and b are said to
be concurrent if a ↛ b and b ↛ a

22. distributed events
• a → b (a happens before b)
• a ↛ b (a does not happen before b)
• 2 distinct events a and b are said to
be concurrent if a ↛ b and b ↛ a
2 events are concurrent if neither can causality affect
each other

23. Applicative functor
scala> (3.some, 2.some) mapN { _ + _ }
res8: Option[Int] = Some(5)
scala> (none[Int], 5.some) mapN { _ - _ }
res9: Option[Int] = None
See 'Oh, All the things you'll traverse' by Luka Jacobowitz

24. for comprehension
getLine flatMap { x =>
print(length(x)) flatMap { _ =>
getLine flatMap { y =>
IO(x ++ y)
}
}
}
for {
x <- getLine
_ <- print(length(x))
y <- getLine
} yield x ++ y
def procedural: Unit = {
val x = getLine
print(length(x))
val y = getLine
x ++ y
}

25. build.sbt DSL
// sbt 0.12 style
foo <<= (compile in Compile, bar) map { (c, b) =>
doSomething(b)
}
// sbt 1.x style
foo := {
val c = (Compile / compile).value
val b = bar.value
doSomething(b)
}

26. build.sbt DSL
// sbt 0.12 style
foo <<= (compile in Compile, bar) map { (c, b) =>
doSomething(b)
}
// sbt 1.x style
foo := {
val c = (Compile / compile).value
val b = bar.value
doSomething(b)
}
Applicative composition

27. build.sbt DSL
foo := {
val c = (Compile / compile).value
val b = bar.value
doSomething(b)
}
Compile / compile bar
foo
"happens before"

28. build.sbt DSL
foo := {
val c = (Compile / compile).value
val b = bar.value
doSomething(b)
}
Compile / compile bar
foo
"happens before"
line of sand in time-space

29. Applicative composition
foo := {
val c = (Compile / compile).value
val b = bar.value
doSomething(b)
}
Test / test := {
val c = (Compile / compile).value
val f = foo.value
}
Compile / compile bar
foo
"happens before"
Test / test
"happens before"

30. why Applicative composition?
Compile / compile bar
foo
"happens before"
Test / test
"happens before"

31. why Applicative composition?
Compile / compile bar
foo
"happens before"
Test / test
"happens before"
1. minimality (executes task at most once, for input
that changed)
evaluated only once

32. why Applicative composition?
Compile / compile bar
foo
"happens before"
Test / test
"happens before"
1. minimality
2. automatic parallel processing

33. act command
• given a task, creates a plan that evaluates the task
in current and aggregated subprojects
• concurrent tasks are evaluated in parallel
lazy val root = (project in file("."))
.aggregate(util, core)
.settings(...)
lazy val util = (project in
file("util"))
.dependsOn(core)
lazy val core = (project in
file("core"))

34. act command
• how does it relate with State?
s0 s1 s2
reload (settings) act (task) act (task)

35. tasks vs commands
• prefer tasks for plugin extension
• tasks compose automatically
• command composition is stateful / sequential

36. ~ command

37. sbt 1.0 - 1.3

38. sbt 1.0 (2017)
• Scala 2.12 (from 2.10)
• build.sbt only
• drop <<=, <+=, <++= operators
• semantic versioning + modularization: Zinc 1

39. sbt 1.1 (2017)
before unified slash syntax
// in build.sbt
scalacOptions in (core, Test, console)
// in sbt shell
core/test:console::scalacOptions
unified slash syntax
core / Test / console / scalacOptions

40. sbt 1.2 (2018)
• SbtPlugin plugin
• cross JDK forking
• addPluginSbtFile command
• experimental thin clients

41. sbt 1.3 (2019)
• library management with Coursier
• super shell
• turbo mode with ClassLoader layering
• IO improvements

42. sbt 1.4+

43. sbt server
• Scala Center and I will collaborate for sbt-bsp
support
• better build IDE integration

44. build linting
• detect settings in build.sbt not used by other tasks.

45. build matrix
• spatial (subproject) representation of cross build
across multiple Scala versions, JVM, JS, and
Native

46. cached compilation
• liberation from machine
• by virtualizing the internal file paths, we can make
them machine-dependent
→

47. modular (incremental)
build pipelining
parser
etc
typer, pickler etc jvm
refcheck,
erasure
parser
etc
typer, pickler etc jvm
refcheck,
erasure
parser
etc
typer, pickler etc jvm
refcheck,
erasure
early/foo.jar
early/bar.jar

48. "sbtw"
• pure Java launcher to replace Bash, Batch, and
current launcher

49. thanks and stay healthy

50. 2020.03 mixtape
COVID-19 real-time update in US (https://
coronavirus.1point3acres.com/en)
Coronavirus update and guidance (https://
www.flattenthecurve.com/)
about me