# Scala 3 (Dotty): what the compiler repository actually contains and how to build it

> The scala/scala3 repository holds the Scala 3 compiler, standard library and language spec. It is a compiler source tree, not a language tutorial, and the README documents exactly one build path.

**scala/scala3** — The Scala 3 compiler, also known as Dotty.

- Repository: https://github.com/scala/scala3
- Website: https://scala-lang.org
- Stars: 6,306 · Forks: 1,180
- Language: Scala
- License: Apache-2.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/scala-scala3

## What scala/scala3 is, and who the repository is written for

The README opens by describing this as the home of the Scala 3 standard library, compiler and language spec. That sentence is the whole scope statement, and it matters because the repository name suggests a language and the contents are a compiler project. The directory listing confirms it: compiler/, library/, library-aux/, library-js/, scaladoc/, scaladoc-js/, presentation-compiler/, language-server/, tasty/, tasty-inspector/, interfaces/, sbt-bridge/, repl/, dist/, tests/ and community-build/ sit side by side. Someone who wants to write Scala 3 applications is in the wrong tree. Someone who wants to change how Scala 3 behaves, or who needs a distribution built from a specific commit, is in the right one. The topics attached to the repository (compiler, dotty, epfl, scala, scala3) point the same way. Dotty is the historical name of the compiler that became Scala 3, and the repository still carries it.

The audience is narrow on purpose. The README links a contributing guide, a filtered issue list for work where help is wanted, and a policy document on LLM-based tools. There is no quickstart for writing a program, no explanation of syntax, and no promise of binary artifacts. The homepage points at scala-lang.org, and the README points at docs.scala-lang.org/scala3/ for more documentation. Both are outside this repository. If your question is how to install Scala 3 on a machine, this repository does not answer it; the README documents building a distribution, which is a different task with a different audience.

## How the tree is organised: compiler, library, TASTy and tooling as separate units

The layout tells you how the project is factored. compiler/ holds the compiler itself. library/ holds the standard library, with library-js/ and library-aux/ as variants or supporting code. tasty/ and tasty-inspector/ deal with TASTy, the typed abstract syntax tree format that Scala 3 uses as its interchange representation, and interfaces/ holds the Java-level interfaces that other tools compile against. That separation is the reason the sbt-bridge/ directory exists: sbt needs to talk to the compiler through a stable surface rather than through compiler internals. presentation-compiler/ and language-server/ are the editor-facing side, and scaladoc/ plus scaladoc-js/ are the documentation generator and its JavaScript output.

The tests directory is not one directory. tests/, sbt-test/, sjs-compiler-tests/, scaladoc-testcases/ and presentation-compiler-testcases/ cover different harnesses, and community-build/ exists to compile a body of external projects against the compiler. bench/, bench-run/ and bench-micro/ are separate benchmarking trees. Read together, the repository is several products sharing a build: a compiler, a standard library, a documentation tool, an editor protocol implementation and a language specification. That is also the main structural cost. A change to the compiler's tree representation can ripple into TASTy, the presentation compiler and the sbt bridge, and the test trees are the only thing standing between you and that ripple.

## Building a local distribution from source

The README documents one build path and nothing else. It says to run sbt dist/Universal/packageBin and then look in dist/target/ for the newly built distributions. That is the entire build section, verbatim in substance: two steps, one command, one output directory. If you have sbt available, the command is:

```bash
sbt dist/Universal/packageBin
```

After it completes, the README states that the built distributions are in dist/target/. Expect archives rather than a bare scala binary, because the task name is packageBin and the output location is a distribution directory. Nothing in the README describes how long the build takes, how much memory it needs, or which JDK to use. The repository does carry .jvmopts, which is where JVM flags for the build live, and build.sbt, which pins the build definition; check both before assuming a default launcher configuration will work.

For a first real use, the honest one is running the test suite in the area you intend to touch, not compiling a Hello World. The README does not give a test command, so the safe move is to open an sbt shell and let the build definition tell you what is available:

```bash
sbt
```

From the shell you can inspect the projects defined in build.sbt and run the test task of the module you are changing. The repository also ships a repl/ directory, so a REPL is part of the build rather than something you fetch separately. What you should see after a successful packageBin is a populated dist/target/; if that directory is empty, the build did not reach the packaging step, and the README offers no troubleshooting guidance beyond the two steps.

## The LLM policy and contribution constraints you meet before writing code

Two files sit at the top level that are unusual to see in a compiler repository: LLM_POLICY.md and AGENTS.md. The README links the LLM policy directly under How to Contribute, which means the project treats the use of LLM-based tools as a governance question rather than a personal one. The README does not summarise what the policy says. That is a gap worth naming: a contributor arriving from the README alone knows a policy exists and not what it requires, so the policy file has to be read before the first patch, not after review feedback. AGENTS.md sits in the same space and, by naming convention, is aimed at automated coding agents.

CONTRIBUTING.md is the other gate, and the README routes all contribution questions through it. The repository also carries SECURITY.md, so vulnerability reports have a stated channel separate from the issue tracker. The practical consequence is that the cost of a first contribution here is not writing Scala. It is reading three or four documents, understanding which test tree your change belongs to, and accepting that a compiler change may need community-build/ to pass before it is considered safe. The README lists an issue filter for work where help is wanted, which is the lowest-friction entry point it offers.

## Where this repository is the wrong tool

If you want to learn Scala 3, this is the wrong repository. There is no tutorial, no exercise set and no guided path in the README; it points to docs.scala-lang.org/scala3/ for documentation and to scala-lang.org as the homepage. If you want a compiler installed on your machine, the README does not document one. It documents producing a distribution from source, which assumes you already have sbt and a working JVM, and it does not tell you how to place the result on your PATH. Anyone whose actual goal is to run a Scala 3 program should get the toolchain from the language's distribution channels, not from this tree.

A second wrong-tool case is smaller but real. If you need a stable, long-lived build for production, the release list shows the shape of the project's cadence: 3.10.0-RC1 and 3.10.0-RC2 in September 2026, alongside 3.3.9-RC1. Three of the most recent releases are release candidates. That is normal for a compiler and it means the newest tags are not the ones you would pin a business-critical build to. The repository's last push was on 2026-09-22, so the main branch moves; a commit hash from today is not a support contract. Finally, if your problem is a library or framework question, nothing in this tree will help. The standard library is here, the ecosystem is not.

## Alternatives, and how their approach differs

The most direct alternative is the Scala 2 compiler, a separate repository and a separate language version. The difference is not merely version numbering. Scala 3 introduces a new metaprogramming model and a new intermediate representation, which is why this tree contains tasty/ and tasty-inspector/ as first-class directories. Scala 2 has no equivalent TASTy layer in this form. The practical consequence for an adopter is that the two compilers do not share an internal architecture, so a fix or a feature in one does not transfer to the other, and the release lines run in parallel rather than in sequence. The README of this repository does not discuss Scala 2 at all, which is itself informative about how the project positions itself.

A second alternative is the JVM language toolchain you already have. Kotlin and Java both ship compiler front ends that most users consume through a build tool, and neither expects you to build the compiler to use the language. That is the real contrast: here, building the compiler is the documented activity, and consuming the language is documented elsewhere. If your goal is to ship software, a toolchain where the compiler is a dependency rather than a project is the shorter path. This repository is for the case where the compiler is the thing you are changing, or where you specifically need a distribution built from a chosen commit.

## Maintenance, upgrade cost and licence implications

The repository is not archived, and its last push was on 2026-09-22, so development is current. The release list shows parallel lines: 3.10.0-RC2 and 3.3.9-RC1 were both published on 2026-09-11, with 3.10.0-RC1 on 2026-09-03. Two active lines mean an upgrade decision is not a single axis. Moving within a line is one kind of change; moving from the 3.3 line to the 3.10 line is another, and the repository gives no migration guidance in the README. The changelogs/ directory is where release history lives, and that is the place to look before pinning a version. The upgrade cost that the README does document is on the build side: the output of dist/Universal/packageBin is a distribution you produce yourself, so every upgrade is a rebuild, and the build definition in build.sbt plus the JVM flags in .jvmopts are the two files that decide whether that rebuild behaves the way your environment expects.

On licensing, the README states that Scala 3 is licensed under the Apache License Version 2.0, and the repository carries both LICENSE and NOTICE.md at the top level. NOTICE.md exists because Apache-2.0 has attribution expectations, and it is the file to read if you redistribute a build. The README also states that the Scala Code of Conduct governs all communication, including GitHub, Discord and email, and links the conduct page. None of this is legal advice; the point is that the repository names its licence, its notice file and its conduct policy explicitly, so there is no ambiguity to resolve by guessing.

## Conclusion

Adopt this repository if you are changing the compiler, the standard library, Scaladoc, the language server, TASTy or the spec, or if you need to build a distribution from source rather than consume one from a package manager. Do not adopt it as your first contact with Scala 3, and do not treat it as the place to install a working toolchain; the README documents no installation path for end users. Before committing time, verify the sbt version your local sbt launcher resolves against build.sbt, confirm the JDK on your machine satisfies .jvmopts, and read LLM_POLICY.md and CONTRIBUTING.md, because the repository states a policy on LLM-based tooling and that policy governs how patches are produced.

## FAQ

### How do I install Scala 3?

The README does not document installing Scala 3. It documents building a local distribution from source with sbt dist/Universal/packageBin and finding the result in dist/target/, so an installation path for end users has to come from elsewhere.

### What is Scala 3?

The README describes this repository as the home of the Scala 3 standard library, compiler and language spec, and the compiler is also known as Dotty. The repository's topics list compiler, dotty, epfl, scala and scala3.

### Which is better, Scala 2 or Scala 3?

The README does not compare the two. What the repository layout shows is that Scala 3 carries TASTy directories and a presentation compiler as first-class parts of the tree, so the two compilers are separate codebases rather than one codebase with a version flag.

### Is Scala still relevant in 2026?

The repository itself does not make that argument. What it shows is an unarchived tree whose last push was on 2026-09-22, with 3.10.0-RC2 and 3.3.9-RC1 both published on 2026-09-11, so two release lines are moving at once.

### What is the difference between Scala 2 and Scala 3?

The README does not spell out the difference. The directory listing shows TASTy and TASTy inspector directories and a presentation compiler inside this tree, which places them in the Scala 3 codebase rather than in a shared one.

## Sources

- [License: Apache-2.0](https://github.com/scala/scala3/blob/main/LICENSE)
- [Project website](https://scala-lang.org)
- [README](https://github.com/scala/scala3/blob/main/README.md)
- [Releases](https://github.com/scala/scala3/releases)
- [scala/scala3 on GitHub](https://github.com/scala/scala3)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/scala-scala3