Tools and packages
Check and format with the compiler alone. Add the native toolchain for executables and application tests.
Everyday commands
| Command | Behavior | Native toolchain |
|---|---|---|
zore check main.ore | Check the file’s whole package; success is silent. | No |
zore fmt . | Format source recursively. | No |
zore fmt --check . | Check formatting without writing. | No |
zore build main.ore | Build an executable in the current directory. | Yes |
zore run main.ore | Build a temporary executable and run it. | Yes |
zore test . | Discover and execute application tests. | Yes, to execute tests |
check, build, and run take a source file. Ordinary files in that file’s folder are compiled together. fmt and test accept a file or directory. Use zore --help for the command surface.
Formatting
zore fmt .
zore fmt --check .
The formatter does not need native build tools, manifests, or dependency resolution. It does not accept dependency flags. Use check mode in CI; the formatter reference describes selection and behavior.
Application tests
Put tests in files ending in _test.ore, using the same package clause as the implementation. A test is a top-level synchronous, non-generic function named Test followed by an ASCII uppercase letter. It takes no arguments and returns nothing or error.
Use ordinary conditions, returned errors, or panics for assertions. The runner checks selected packages before execution, then runs each test in a fresh native process. The package’s main function is not called. A failed test does not prevent later tests from running.
zore test .
Executing tests needs the native toolchain. A selection with no tests still checks its packages and does not require native tools. There is no implicit test timeout, so bound potentially hanging suites in your caller or CI. See the testing reference and complete application-test example.
Packages and imports
A folder is a package. Import paths select project packages, explicitly declared local dependencies, pinned Git dependencies, or bundled standard packages. Visibility is checked across package boundaries and import cycles are rejected.
Start with the local dependency reference for projects on disk. For shared dependencies, use the Git and lockfile reference and tagged dependency reference. Dependency identity and versions are explicit; there is no implicit registry lookup.
Lockfiles and offline use
In a project with zore.toml, install dependencies and generate zore.lock. Commit the lockfile. Use locked commands to consume it unchanged:
zore install .
zore install --locked .
zore check --locked --offline main.ore
zore build --locked --offline main.ore
zore test --locked --offline .
install --locked can populate a missing cache while preserving the committed lock. Offline commands require every selected source to be cached already. check, build, run, and test never fetch dependencies or write a lockfile; missing data points you to installation.
When you intentionally change dependency selections, review the manifest change and run zore lock .. Manifest bytes, including line endings, participate in integrity checks. Do not hand-edit a lockfile.
Bundled standard packages
The published compiler embeds these packages and its runtime sources. No compiler checkout is needed to import them. These links open the alpha’s source API reference:
The library covers text and bytes, collections, files and processes, contexts and synchronization, TCP networking, HTTP, JSON, and time. Individual APIs have ownership and platform constraints; an import’s presence does not imply parity with another language’s standard library.
Native libraries and host behavior
Curated native adapters support registered C/Rust sources and static linking under locked recipes. They do not introduce source-level raw pointers or an unsafe escape hatch. Read the native library reference and platform guide before depending on host-specific behavior.
Reviewed against Zore v0.1.0-alpha.1 · compiler source edcf5847b259f28ef0bbd1409a8c6751b39725cb. Upstream examples © Zore contributors, Apache 2.0.