SBT y Scala CLI en 2026: herramientas de build para proyectos Scala modernos

Construir proyectos Scala ha sido durante años sinónimo de SBT, y SBT tenía fama de ser difícil. Curva de aprendizaje empinada, tiempo de arranque elevado y una DSL que no siempre resulta intuitiva. En 2026, la situación es más clara: SBT sigue siendo el estándar para proyectos grandes y serios, pero Scala CLI ha cambiado completamente la historia para todo lo demás.

Scala CLI: el runner oficial desde Scala 3.3

Scala CLI se convirtió en el runner oficial de Scala con la versión 3.3 LTS. Es la herramienta que se invoca cuando escribes scala en la terminal. Está pensada para casos de uso donde SBT es excesivo: scripts, proyectos pequeños, experimentación y aprendizaje.

// hola.scala
@main def hola(): Unit =
  println("Hola desde Scala CLI")

// Ejecutar directamente
// $ scala-cli run hola.scala

// Con dependencias declaradas en el fichero
//> using dep "com.lihaoyi::os-lib:0.9.1"
//> using scala "3.3.3"

import os.*
@main def listFiles(): Unit =
  os.list(os.pwd).foreach(p => println(p.last))

La directiva //> using dep en el propio fichero Scala es una de las ideas más prácticas: no hace falta crear un proyecto con estructura de directorios ni un build.sbt para añadir una dependencia. Scala CLI la descarga de Maven Central, la cachea y listo.

Comandos principales de Scala CLI

Los comandos que usarás más:

• scala-cli run Main.scala — compila y ejecuta
• scala-cli test . — ejecuta los tests del proyecto
• scala-cli package Main.scala -o mi-app — genera un ejecutable
• scala-cli repl — abre un REPL con las dependencias del proyecto cargadas
• scala-cli fmt . — formatea el código con Scalafmt
• scala-cli doc . — genera documentación

Para proyectos más estructurados, puedes mover las directivas //> using a un fichero project.scala en la raíz del directorio, que actúa como configuración del proyecto sin ser un build.sbt completo.

SBT 1.x: el estándar para proyectos grandes

SBT sigue siendo la herramienta de build de referencia para proyectos Scala de producción. Su modelo de build incremental con Zinc es muy eficiente: solo recompila lo que ha cambiado, y en proyectos grandes eso marca una diferencia real.

Un build.sbt típico para un proyecto con múltiples módulos:

val scala3Version = "3.3.3"

lazy val root = project
  .in(file("."))
  .aggregate(core, api, web)

lazy val core = project
  .in(file("core"))
  .settings(
    name := "mi-app-core",
    scalaVersion := scala3Version,
    libraryDependencies ++= Seq(
      "dev.zio" %% "zio"      % "2.1.0",
      "dev.zio" %% "zio-test" % "2.1.0" % Test
    )
  )

lazy val api = project
  .in(file("api"))
  .dependsOn(core)
  .settings(
    name := "mi-app-api",
    scalaVersion := scala3Version
  )

lazy val web = project
  .in(file("web"))
  .dependsOn(api)
  .settings(
    name := "mi-app-web",
    scalaVersion := scala3Version
  )

Plugins SBT imprescindibles

El ecosistema de plugins de SBT es amplio. Los más usados en 2026:

• sbt-native-packager: genera paquetes Docker, RPM, DEB y ejecutables nativos.
• sbt-assembly: crea fat JARs con todas las dependencias, útil para Spark.
• sbt-scoverage: cobertura de tests. Genera informes HTML y se integra con CI.
• scalafmt: formateador de código. Se configura en .scalafmt.conf.
• scalafix: refactoring automático y lint. Tiene reglas para migración de Scala 2 a Scala 3.

SBT 2.x en el horizonte

SBT 2.x lleva un tiempo en desarrollo y trae cambios importantes. El modelo de build se está reescribiendo para ser más predecible y la integración con Zinc mejora. Sin embargo, a mediados de 2026 SBT 1.x sigue siendo el estándar de facto para proyectos en producción. La migración a SBT 2.x no es urgente.

Mill: la alternativa silenciosa

Mill es una alternativa a SBT creada por Li Haoyi (el mismo autor de Ammonite y de librerías como uPickle o Requests-Scala). La sintaxis de Mill es Scala puro sin DSL especial, lo que muchos desarrolladores encuentran más fácil de razonar. No tiene la adopción de SBT en proyectos grandes, pero para proyectos medianos es una opción a considerar.

Cuándo usar cada herramienta

La guía práctica es sencilla: Scala CLI para scripts, proyectos de un solo fichero o ficheros y aprendizaje. SBT para proyectos de producción con múltiples módulos, pipelines de CI/CD y equipos. Mill como alternativa si SBT te resulta opaco y prefieres configuración en Scala puro.

Para quien viene de otros lenguajes, la comparativa más cercana sería: Scala CLI es como cargo run en Rust o como go run en Go. SBT es más parecido a Gradle en el mundo Java.

Imagen: Pexels / Daniil Komov