Scala
Completed
-
Section 1: Getting Started
-
Section 2: Core Syntax
-
Section 3: Object-Oriented Scala
-
Section 4: Functional Scala
-
Section 5: Collections in Depth
-
Section 6: Type System
-
Section 7: Concurrency and Ecosystem
-
Section 8: Practical Projects
-
Section 9: Interview Practice
-
Section 10: Data Structures and Algorithms in Scala
-
Section 11: More Practice Exercises
-
Section 12: Advanced Functional Patterns
-
Section 13: More Ecosystem
-
Section 14: Scala Collections Library Deep Dive
-
Section 15: Scala Standard Library Deep Dive
-
Section 16: Akka Ecosystem Deep Dive
-
Section 17: Cats and Cats Effect Deep Dive
-
Section 18: Play Framework Deep Dive
-
Section 19: Apache Spark with Scala Deep Dive
-
Section 20: Scala Build Tools Deep Dive
-
Section 21: Scala 3 Specific Features
-
90: Union and Intersection Types
-
Section 22: Scala Testing Deep Dive
-
Section 23: Functional Domain Modeling
-
Section 24: More Data Structures and Algorithms in Scala
-
Section 25: Scala for Data Engineering
-
Section 26: More Practical Projects
-
Section 27: More Interview and Review
-
Section 28: ZIO Ecosystem Deep Dive
-
Section 29: Scala for Machine Learning
-
Section 30: Scala Microservices Architecture
-
Section 31: Scala Type System Deep Dive
-
Section 32: More Practice and Drills
-
Section 33: Scala Performance Deep Dive
-
Section 34: Scala Ecosystem Tooling
-
Section 35: Scala for Reactive Systems
-
Section 36: More Real-World Case Studies
-
Section 37: Scala for Financial Systems
-
Section 38: Scala GraphQL and gRPC
-
Section 39: More Final Projects
-
Section 40: More Interview and Final Review
-
Section 41: Scala for Streaming Data
-
Section 42: Scala Security Practices
-
Section 43: More Language Deep Dive
-
Section 44: Scala Command-Line Tools
-
Section 45: Scala Documentation and Style
-
Section 46: Scala Dependency Management
-
Section 47: More Practical Backend Patterns
-
Section 48: Scala for Event-Driven Architecture
-
Section 49: More Practice Drills Round 2
-
Section 50: Scala Compiler Deep Dive
-
Section 51: Scala for Web Frontends
-
Section 52: More Data Engineering Practice
-
Section 53: Scala Observability
-
Section 54: More Advanced Practice Projects
-
Section 55: Scala for Legacy Java Integration
-
Section 56: More Testing Practice
-
Section 57: Final Mastery Review
-
Section 58: Scala History and Ecosystem Context
-
Section 59: More Concurrency Patterns
-
Section 60: Scala for Configuration Management
-
Section 61: More Domain Modeling Practice
184: Managing Dependencies in sbt
I was working on a small utility recently to parse some JSON configuration files, and I decided to use upickle because it's fast and doesn't require a mountain of boilerplate. I jumped straight into the code, feeling productive, and wrote this:
import upickle.default._
case class AppConfig(port: Int, host: String)
object AppConfig {
implicit val rw: ReadWriter[AppConfig] = macroRW
}
val json = """{"port": 8080, "host": "localhost"}"""
val config = read[AppConfig](json)
println(s"Starting server on ${config.host}:${config.port}")
The Missing Symbol Headache
Of course, the compiler immediately turned red. cannot find symbol upickle. I paused for a second—I'm so used to the IDE handling things that I completely forgot that Scala doesn't just "know" where external libraries live. Unlike the standard library, upickle isn't baked into the language. It lives in a repository (usually Maven Central), and my project has no idea it's supposed to be there.
If I just keep adding imports, I'm just fighting a losing battle. I need to tell sbt (the Scala Build Tool) to go fetch this specific piece of code and make it available on my classpath during compilation.
Telling sbt where to look
I opened my build.sbt file. Right now, it's pretty bare. To fix this, I need to add a libraryDependencies setting. I've seen people just copy-paste these lines, but let's look at the anatomy of the line I'm adding:
libraryDependencies += "com.lihaoyi" %% "upickle" % "3.1.0"
Wait, why the double percent %%? I remember this tripping me up early on. A single % is used for Java libraries. But Scala has a problem: binary compatibility between versions (like 2.12 vs 2.13 vs 3). If I use %%, sbt automatically appends the Scala version I'm using to the artifact name. It turns upickle into upickle_2.13 (or whatever version you're on) behind the scenes. It saves us from manually tracking which version of the library matches our compiler.
I saved the file, and sbt automatically reloaded. I checked the console, saw a flurry of downloads, and suddenly the red squiggly lines in my editor vanished. The code now compiles because sbt downloaded the JAR and told the compiler, "Hey, look in here for the upickle package."
Cleaning up the production classpath
Now, I wanted to write a test to make sure my JSON parsing doesn't blow up if the input is malformed. I decided to use munit for the testing framework. My first instinct was to just add it the same way:
libraryDependencies += "org.scalameta" %% "munit" % "0.7.29"
That works, but there's a problem. If I package this app into a JAR to ship it to a server, I don't want the testing framework bundled in. I don't need munit to run the actual app; I only need it while I'm developing and running tests. Including it in the production build just bloats the file.
I adjusted the line to use a "scope":
libraryDependencies += "org.scalameta" %% "munit" % "0.7.29" % Test
By adding % Test at the end, I'm telling sbt: "Download this, use it when I run sbt test, but keep it completely out of the main compilation and the final production artifact." It's a small detail, but in a large professional project with hundreds of dependencies, managing these scopes is the difference between a 50MB JAR and a 500MB JAR.
📋 Practical Task
Building a File-Counting Utility with os-lib
Your task is to set up a new Scala project that uses the os-lib library (a popular library for file system operations) to count how many files exist in a specific directory. You will also need to add a testing framework that is only available during the test phase.
Requirements:
- Modify your
build.sbtto includeos-lib(groupId:com.lihaoyi, artifactId:os-lib, version:0.9.1) as a compile-time dependency. - Add
munit(groupId:org.scalameta, artifactId:munit, version:0.7.29) as a test-scope dependency. - In your main code, use
os.list(".")to get a list of files in the current directory and print the size of that list. - Ensure the project compiles and that
os-libis accessible in the main source folder, butmunitis only accessible if you were to create a file insrc/test/scala.
There are no comments for now.