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 PHP-bootstrap prerelease contains Baton, doriac, doria-lsp, and Baton's
isolated private runtime. After the mandatory native cutover, production
toolchains contain the Doria-native Baton executable, doriac, and doria-lsp
with no Baton PHP payload. Neither layout requires Rust, Cargo, system PHP,
Composer, or a repository checkout.
Run baton doctor after installation to verify component versions and hashes,
host compatibility, a real native compiler/runtime/linker probe, and writable
project/cache locations. Bootstrap prereleases also verify their private
runtime.
| 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 install |
Install the exact locked dependency graph, or create its first lock |
baton add <package> ... |
Add and lock a normal path or Git dependency |
baton remove <package> |
Remove a direct normal dependency and update the lock |
baton update [package ...] |
Deliberately refresh all or selected dependency resolutions |
baton fetch [package ...] |
Acquire exact locked content without editing project files |
baton test [--filter <text>] |
Discover low-level and behavioral tests from compiler metadata and run each in a fresh process |
baton tree [--development] |
Show the exact locked dependency tree |
baton why <package> [--development] |
Explain every locked path to a package |
baton project --json [--development] --offline |
Emit the local project inventory used by tooling |
--binary <name> |
Select a declared binary for check, build, or run |
--library |
Select the declared library for check or source-only build |
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 = 2
[package]
name = "hello-doria"
version = "0.1.0"
edition = "2026"
publishable = false
kind = "binary"
entry = "src/main.doria"
[autoload.namespaces]
"" = "src/"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.
Schema-2 build artifacts are written beneath
build/<host-target>/<profile>/<target-name>/. Baton never uses Cargo's
target/ convention for Doria project output. Existing schema-1 projects keep
their historical non-target-scoped layout.
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.
Stage 33 is complete in this bootstrap. Strict manifest schema 2 now covers compile-time source discovery, explicit targets, path and Git sources, workspaces, development dependencies, processors, tests, graph inspection, and deterministic project inventory. Standalone schema-1 manifests and locks retain their exact historical behavior; workspaces use lock schema 2.
Stage 33 implements and exercises that complete product contract in this
disposable bootstrap. It does not make PHP Baton's permanent implementation.
After the required Doria tooling foundations land, the mandatory Pre-Stage-45
transition parity-ports the frozen behavior to the clean dorialang/baton
repository. The unsuffixed 2026.03.1 release is blocked until production
toolchains use the native Baton executable and carry no Baton PHP runtime.
The Native Testing Foundation is complete. Compiler-owned expectations run
through baton test without Baton parsing Doria source or human diagnostics.
Baton strictly decodes the compiler/runtime-owned DORIAO2, DORIAO3, and DORIAO4
outcome records, classifies each isolated process as passed, assertion failed,
unexpected checked Error, fatal panic, or abnormal process failure, and reports
compiler-authored suite hierarchy in source order. Collection and checked-Error
expectations use the same structured boundary; Stage 34 is now the next language
stage.
See Phase F package and dependency model for the complete target contract and its current-state boundary.
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.
Until the native cutover, 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;
- prerelease 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.
The clean dorialang/baton repository will own the production Doria-native
Baton, templates, and complete toolchain releases after the parity-gated
Pre-Stage-45 transition. This repository then freezes as historical bootstrap
and compatibility reference.
Read Architecture for the component and ownership model.
- Project manifest
- Package targets
- Source discovery
- Compiler build plans
- Dependencies
- Lockfile
- Dependency cache
- Offline operation
- Workspaces
- Testing
- Attribute processors
- Project inventory
- Incremental inventory
- Phase F package and dependency model
- 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.
Apache License 2.0. See LICENSE. Third-party components retain their own licenses and notices.