Belajar Scala - sbt & Build Tooling

#Pendahuluan

Selama episode 3-8, kalian menjalankan semuanya dengan scala run — file tunggal tanpa build tool. Itu pilihan tepat untuk belajar sintaks. Sekarang saatnya dewasa: proyek produksi Scala dibangun dengan sbt, build tool standar yang mengelola kompilasi, dependensi, testing, dan packaging secara bersamaan.

Mengapa episode ini penting? Karena sbt adalah lingkungan kerja kalian selanjutnya. Semua library yang kita bahas mulai episode 10 — MUnit, cats-effect, http4s, Doobie — diimpor lewat sbt. Memahami build.sbt bukan opsional; ia adalah jembatan antara kode kalian dan seluruh ekosistem Scala.

#Inisialisasi Proyek sbt

Install sbt dulu via Coursier:

cs install sbt
sbt --version

Lalu buat proyek baru:

mkdir ~/scala-app && cd ~/scala-app
sbt new scala/scala3.g8

scala3.g8 adalah template resmi Giter8 untuk Scala 3. Setelah menjawab beberapa pertanyaan, struktur proyeknya:

scala-app/
  build.sbt
  project/
    build.properties
  src/
    main/scala/Main.scala
    test/scala/

Ini konvensi wajib sbt: kode produksi di src/main/scala, kode test di src/test/scala.

#Membaca build.sbt

File paling penting adalah build.sbt:

ThisBuild / scalaVersion := "3.3.8"
 
ThisBuild / organization := "com.example"
 
lazy val root = project
  .in(file("."))
  .settings(
    name := "scala-app",
    version := "0.1.0",
    libraryDependencies ++= Seq(
      "org.scalameta" %% "munit" % "1.0.0" % Test
    )
  )

Beberapa hal untuk dipahami:

• scalaVersion := "3.3.8" — memakai versi LTS. Untuk series ini di episode 20 kita akan membahas kenapa LTS dipilih untuk library/produksi.
• name, version, organization — metadata artefak.
• libraryDependencies — daftar dependensi, dengan sintaks "org" %% "artifact" % "version".
• %% — "pindahkan ke versi Scala": "org.scalameta" %% "munit" otomatis menjadi munit_3 untuk Scala 3.

#Siklus: compile, test, run

Saat di direktori proyek, jalankan perintah sbt:

sbt compile   # kompilasi kode produksi
sbt test      # kompilasi + jalankan test
sbt run       # kompilasi + jalankan Main

sbt bisa juga dibuka sebagai shell interaktif — kalian ketik perintah di dalamnya:

sbt
sbt:scala-app> compile
sbt:scala-app> run
sbt:scala-app> test

Pertama kali, sbt mengunduh dependensi (bisa beberapa menit). Setelah itu, kompilasi incremental membuat siklus edit → compile terasa cepat. Metals memanfaatkan sbt ini untuk memberikan error live di editor.

#Menjalankan via Main Class

Jika ada beberapa entry point, tentukan yang mana:

lazy val root = project
  .in(file("."))
  .settings(
    name := "scala-app",
    version := "0.1.0",
    Compile / mainClass := Some("Main"),
    libraryDependencies ++= Seq(
      "org.scalameta" %% "munit" % "1.0.0" % Test
    )
  )

Main.scala di src/main/scala:

@main def helloApp(): Unit =
  println("Aplikasi Scala berjalan!")

#Scala CLI dan Using Directives

Scala CLI adalah build tool lain yang kalian sudah kenal secara tidak langsung: itulah mesin di balik scala run sejak 3.5. Keunggulannya adalah workflow single-file dan using directives untuk dependency:

//> using scala "3.3.8"
//> using dep "org.typelevel::cats-core:2.13.0"
 
import cats.implicits.*
 
@main def run(): Unit =
  println(List(1, 2, 3).map(_ + 1).mkString(", "))

scala run main.scala

Untuk membuat package atau menjalankan test:

scala compile main.scala
scala test .
scala package . -o app.jar --assembly

Scala CLI sangat cocok untuk script, tooling, dan pembelajaran. sbt untuk proyek produksi berukuran sedang-besar. Pilihan mana yang tepat akan kita rekap di episode 22.

#Mill: Alternatif Build Modern

Mill adalah build tool yang ditulis di Scala dan memakai sintaks Scala langsung sebagai build script — tanpa DSL terpisah seperti build.sbt:

import mill._, scalalib._
 
object app extends ScalaModule:
  def scalaVersion = "3.3.8"
  def ivyDeps = Agg(
    ivy"org.scalameta::munit:1.0.0"
  )

./mill app.compile
./mill app.test
./mill app.run

Mill menawarkan determinisme dan build graph yang lebih transparan, dengan startup yang biasanya lebih cepat daripada sbt. Komunitasnya lebih kecil, tetapi berkembang — terutama untuk project yang menginginkan build config sebagai kode Scala murni.

#Perbandingan Build Tool

#Common Pitfalls

• %% tertukar % — memakai % untuk library Scala menyebabkan artefak tidak ditemukan; pakai %% untuk library Scala, % untuk Java.
• Kode di folder salah — src/main/scala untuk produksi, src/test/scala untuk test; menaruhnya di tempat lain membuat sbt tidak mengenalinya.
• Versi library yang tidak kompatibel dengan Scala 3 — library lama mungkin hanya untuk Scala 2; cek index.scala-lang.org untuk status cross-build.
• Menunggu kompilasi ulang penuh — sbt memakai incremental compilation; perubahan satu file hanya memicu kompilasi file terkait.

#Penutup

Inti yang harus dibawa pulang:

• sbt adalah build tool standar: build.sbt mendeklarasikan scalaVersion dan libraryDependencies.
• Struktur wajib: src/main/scala (produksi) dan src/test/scala (test).
• Siklus dasar: sbt compile, sbt test, sbt run.
• %% menyesuaikan nama artefak dengan versi Scala; % untuk library Java.
• Scala CLI (using directives) dan Mill adalah alternatif untuk skenario yang berbeda.

Di episode 10 selanjutnya, kita membuat kode kalian bisa diuji: testing dengan MUnit dan ScalaTest, plus debugging dengan Metals — assertion, struktur test suite, dan breakpoints di VS Code. Sampai jumpa di episode 10!