Scala 3 (Dotty): compiler, library, and spec in one tree

Three deliverables share one top level

This is not a compiler repository alone. The project describes itself as the home of the Scala 3 standard library, the compiler, and the language spec, three deliverables that would sit in three separate trees in most language ecosystems. The directory listing follows that split: compiler/ holds the compiler work, library/, library-js/, and library-aux/ sit beside it, and docs/ covers the specification and documentation. The default branch is main, the primary language is Scala, the license is Apache License 2.0, and the declared homepage is scala-lang.org. Documentation is pointed at docs.scala-lang.org/scala3/. Two more entries, staging/ and tasty/, are tracked as separate directories rather than being folded into compiler/.

The one documented command builds a distribution into dist/target

The only executable instruction in the README builds the project instead of installing it. It is a two step numbered list: run the sbt packaging task, then collect the newly built distributions from dist/target/.

sbt dist/Universal/packageBin

The result lands under dist/target/. Nothing else is offered. There is no download URL, no package manager line, no version flag, and no coursier invocation. The dist/ entry is the module that produces those artifacts, and it lives in the same tree as compiler/, library/, and repl/ rather than in a separate release repository. Both steps assume you already have sbt installed and a JDK available, and the README names no version for either of those tools.

There is no install command to find in the file listing

Look for an installation section and there is not one. No curl line, no brew or sdkman entry, no archive to unpack. What the README supplies is a build, and a build is a different thing from a release: a person who follows the sbt task ends up holding whatever their local checkout produced rather than a numbered, signed artifact. That gap becomes visible when the two are placed side by side. The release list shows 3.10.1-RC1 published on 2026-10-25, while the tree's last recorded push is 2026-11-02. The README does not explain how a distribution built from main relates to a release candidate line, so anyone who needs a pinned compiler has to resolve that outside this file.

The tree names internal stages without explaining them

The top level reads like a map of compiler internals, and the README annotates almost none of it. Entries such as directives-parser/, interfaces/, repl/, presentation-compiler/, sbt-bridge/, tasty-inspector/, scaladoc/, and staging/ are all there. Three more carry names that read as measuring, bench/, bench-micro/, and bench-run/. A third group is about proving the build works: tests/, sbt-test/, community-build/, presentation-compiler-testcases/, scaladoc-testcases/, and sjs-compiler-tests/. The listing tells you the work is sliced along these lines and roughly how much of it sits in each slice. It does not tell you what a single directory contains, what order the stages run in, or which of them a newcomer can affect alone. That missing map is the practical cost of a short README.

Two candidate lines are visible at the same time

The recent release list mixes a final release and candidates. 3.3.9 LTS carries a date of 2026-10-28, 3.10.1-RC1 carries 2026-10-25, and 3.3.9-RC2 carries 2026-10-09. So a 3.3.9 LTS line reached a final release while a separate 3.10.1 line produced a candidate in the same window. That shape tells you the tree supports parallel release lines, but the README says nothing about which line receives fixes, how long each is supported, or whether the two lines are meant to converge. Anyone choosing between them has to read the release notes rather than this file. The repository is not archived, and the last push on the default branch is dated 2026-11-02.

Contribution rules reach past the issue tracker

Three files and one filtered issue view carry the contributor rules. CONTRIBUTING.md is the guide. The issue tracker is linked through a search for open issues carrying the label help wanted, which is the documented way to find work. LLM_POLICY.md sets out what the project expects from LLM-based tools used on the codebase. Conduct comes from the Scala Code of Conduct, and the README states its scope in plain terms: it applies to all communication and discussion, including GitHub, Discord, and more direct lines such as email. A separate entry named SECURITY.md sits in the tree, but the README does not say what a security report should contain, where it should go, or what response to expect.

Supported versions and platforms are never named

Ask what the resulting compiler supports and the README goes quiet. There is no JDK range, no minimum Java version, and no target platform list, even though library-js/ and sjs-compiler-tests/ sit in the tree where JavaScript facing work would live. The changelogs/ directory appears as a name only, with no indication of format or entry point. There is also no migration guidance for people arriving from earlier Scala versions, which is the largest open question for anyone evaluating the language today. What can be verified from the files is narrow and worth stating plainly: Apache License 2.0, homepage scala-lang.org, docs at docs.scala-lang.org/scala3/, and the single packaging task.

Editorial conclusion

Judge this repository as a source tree and a build target, not as something you install from it. Use it when you want to read the implementation, contribute through the labelled help wanted issues, or build a distribution you can test yourself. Do not expect the README to settle your tooling questions, because it names no JDK range, no supported platforms, and no install command. Before depending on a specific build, confirm the version yourself against the release notes, since the recent candidates and the default branch move independently.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. scala/scala3 on GitHub