Baton gives Doria projects one consistent command-line workflow. It creates projects, validates manifests, selects the compiler shipped with the active Doria toolchain, and coordinates checking, building, and running programs without taking ownership of language semantics.
Install the Doria toolchain for your platform, then create and run a project:
baton new hello-doria
cd hello-doria
baton runA Doria toolchain distribution contains Baton, doriac, doria-lsp, and the private runtime Baton needs. Using it does not require Rust, Cargo, PHP, Composer, or a repository checkout.
Run baton doctor after installation to verify component versions and hashes,
the private runtime, host compatibility, and writable project/cache locations.
| Command | Purpose |
|---|---|
baton new <name> |
Create a Doria binary project |
baton check |
Type-check the current project without producing a binary |
baton build |
Build the current project using the development profile |
baton build --release |
Build an optimized release artifact |
baton run -- [args...] |
Build and run the project, forwarding program arguments |
baton doctor |
Report and verify the installed toolchain |
baton version |
Print Baton and compiler versions |
Baton searches the current directory and its parents for Baton.toml, so project commands also work from a subdirectory.
Use baton run --release to run the release profile. Everything after -- is passed to the program unchanged:
baton run -- --port 8080 "two words"A normal run displays only the program's output. Use -v, -vv, or -vvv to include compiler and build details; build failures are always shown.
baton new hello-doria creates:
hello-doria/
├── Baton.toml
└── src/
└── main.doria
The project manifest is deliberately small:
manifest-version = 1
[package]
name = "hello-doria"
version = "0.1.0"
kind = "binary"
entry = "src/main.doria"Package versions use SemVer. Doria toolchain releases use CalVer, such as 2026.03.1 or 2026.03.1-canary; the two version domains are independent.
Build artifacts are written beneath build/<host-target>/<profile>/. Baton never uses Cargo's target/ convention for Doria project output.
Each profile directory also contains build.json, recording the package, package version, toolchain, target, and profile that produced the artifact.
See Project manifest for the field contract and path rules.
Baton prefers the compiler recorded in the installed toolchain.json, then a compiler shipped beside Baton. It does not silently substitute an unrelated doriac from PATH.
Before invoking the compiler, Baton verifies its machine-readable identity, toolchain version, platform, architecture, and—when selected through the installed manifest—its SHA-256 digest. Compiler diagnostics and exit codes pass through unchanged.
See Toolchain discovery and validation for the complete selection order and development overrides.
This repository owns:
- the Baton command-line experience;
Baton.tomlloading and project discovery;- project templates and build layout;
- compiler discovery and safe process invocation;
- private runtime packaging;
- final Doria toolchain assembly and distribution tests.
The dorialang/doria repository owns the language, compiler, and compiler component artifacts. The dorialang/doria-language-server repository owns doria-lsp and editor integrations.
Read Architecture for the component and ownership model.
- Project manifest
- Toolchain discovery and validation
- Private Baton runtime
- Architecture
- Release process
- Development plan
- Changelog
- Contributing
- Security policy
Baton's source-development workflow uses PHP 8.4 and Composer 2. These are contributor requirements only; they are not user installation requirements. See CONTRIBUTING.md for setup, validation, and compiler-integration guidance.
MIT. See LICENSE.