Scarb
Scarb manifest file (Scarb.toml)
Scarb.toml
Validate
Check your file against this schema
Opens the validator with this schema already loaded. Paste your
Scarb.toml and it validates in your browser — nothing is uploaded.
Reference
Fields
Generated directly from the schema, following local
$refs, to two levels of nesting.
| Field | Type | Description |
|---|---|---|
cairo | anyOf | Global Cairo compiler configuration for this package or workspace profile. - See official documentation at: <https://docs.swmansion.com/scarb/docs/reference/manifest.html#cairo> |
cairo-plugin | anyOf | The `[cairo-plugin]` target describing a Cairo compiler plugin artifact. |
dependencies | object | null | The `[dependencies]` table for normal build dependencies. Your packages can depend on other libraries from registries, Git repositories, or subdirectories on your local file system. - See official documentation at |
dev-dependencies | object | null | The `[dev-dependencies]` table for dependencies used only in tests. Development dependencies are not used when compiling a package for building, but are used for compiling tests. These dependencies are not propagated to other packages |
executable | anyOf | The `[executable]` target describing how to build an executable entrypoint. The executable target defines an artifact that can be executed with `scarb execute` command. This target should be used for packages that are meant to be executed |
features | object | null | The `[features]` table defining feature flags for conditional compilation. - See official documentation at: <https://docs.swmansion.com/scarb/docs/reference/conditional-compilation.html#features> |
lib | anyOf | The `[lib]` target describing how to build the package library. The library target defines a "library" that can be used by other packages. In other words, if a package does not provide a library target, it cannot be used as a dependency |
package | anyOf | The `[package]` section with metadata about the current package. Required for non-workspace members. Contains fields like `name`, `version`, `edition`, `publish`, `license`, etc. |
patch | object | null | The `[patch.<source>]` tables to override dependency sources. Useful to redirect packages to local paths or forks for the resolver. - See official documentation at |
profile | object | null | The `[profile]` table defining build profiles. Common profiles are `dev` and `release`. Each profile can override `cairo` options and `tool` settings, and may `inherit` from another profile. - See official documentation at |
scripts | object | null | The `[scripts]` table with custom commands you can run via `scarb run <name>`. Script commands are simple shell snippets; in workspaces, they can be marked with `{ workspace = true }` to indicate inheritance. - See official documentation |
target | object | null | The `[[target.*]]` tables to define additional, custom-named targets. |
target-defaults | object | null | The `[target-defaults]` table to define defaults applied to targets (for example, test settings) when not explicitly set on a target. - See official documentation at |
test | array | null | The `[[test]]` array of tables defining external test suites. Each table describes a test target with its own parameters. When absent, Scarb may auto-detect tests under the default tests directory. - See official documentation at |
tool | object | null | The `[tool]` table for third‑party tool configuration namespaces. Keys under `tool.<name>` are passed to external tools. Use `{ workspace = true }` to opt into workspace inheritance when applicable. - See official documentation at |
workspace | anyOf | The `[workspace]` section defining a multi-package workspace. Lets you list `members`, define shared `dependencies`, `scripts`, and defaults inherited by workspace members. |
Audit
What we found in this schema
- Declared draft: 2020-12
- 106 properties, 93% carrying a description, max nesting depth 7.
Standards
Specification sections for the keywords in this schema
| Keyword | Document | Section |
|---|---|---|
$defs | JSON Schema Core, draft 2020-12 | §8.2.4 — Schema Re-Use With "$defs" |
$id | JSON Schema Core, draft 2020-12 | §8.2.1 — The "$id" Keyword |
$ref | JSON Schema Core, draft 2020-12 | §8.2.3.1 — Direct References with "$ref" |
$schema | JSON Schema Core, draft 2020-12 | §8.1.1 — "$schema" |
additionalProperties | JSON Schema Core, draft 2020-12 | §10.3.2.3 — "additionalProperties" |
anyOf | JSON Schema Core, draft 2020-12 | §10.2.1.2 — "anyOf" |
description | JSON Schema Validation, draft 2020-12 | §9.1 — "title" and "description" |
format | JSON Schema Validation, draft 2020-12 | §7 — Vocabularies for Semantic Content With "format" |
items | JSON Schema Core, draft 2020-12 | §10.3.1.2 — "items" |
properties | JSON Schema Core, draft 2020-12 | §10.3.2.1 — "properties" |
required | JSON Schema Validation, draft 2020-12 | §6.5.3 — "required" |
type | JSON Schema Validation, draft 2020-12 | §6.1.1 — "type" |
format: "uri" | RFC 3986 (STD 66) | §3 — Syntax Components |
Documents
- JSON Schema Core, draft 2020-12 — JSON Schema: A Media Type for Describing JSON Documents, A. Wright, H. Andrews, B. Hutton, G. Dennis, Eds., 2022. draft-bhutton-json-schema-01. An expired Internet-Draft with no formal standing in the IETF standards process; it is nonetheless the specification of record for JSON Schema 2020-12, published by json-schema.org.
- JSON Schema Validation, draft 2020-12 — JSON Schema Validation: A Vocabulary for Structural Validation of JSON, A. Wright, H. Andrews, B. Hutton, Eds., 2022.
- RFC 8259 (STD 90) — The JavaScript Object Notation (JSON) Data Interchange Format, T. Bray, Ed., 2017. The format a schema describes.
- RFC 6901 — JavaScript Object Notation (JSON) Pointer. Defines the pointer syntax used by $ref fragments and the ~0 / ~1 escapes.
Source
Attribution
This schema comes from SchemaStore, distributed under the Apache License 2.0. Copyright 2015–present Mads Kristensen and contributors. View the original file. The field table and audit on this page are generated by JSONTools.tools; the schema itself is unmodified.