Project manifest

Informative guide. This Book page explains Beskid but does not define the standard. For normative requirements, use the Beskid Standard.

Project manifests use the .bproj extension and BSOL block syntax—HCL-like blocks parsed by Beskid tooling, not full Terraform HCL, not JSON with extra steps. One file per project directory, explicit intent.

Legacy Project.proj is rejected (E1894); rename to <name>.bproj.

Minimal shape

MyApp/
├── MyApp.bproj
├── Src/
│   └── Main.bd
├── obj/
│   └── beskid/
└── Project.lock

MyApp {
  name    = "MyApp"
  version = "0.1.0"
  root    = "Src"
  root_namespace = "Company.Product"
}

target "App" {
  kind  = App
  entry = "Main.bd"
}

dependency "Std" {
  source = path
  path   = "../Std"
}

The root block kind MyApp must match name = "MyApp".

Block roles

• Named root block { ... } — identity, version, source root (root, default Src), optional root_namespace (metadata for package namespace conventions; does not change file-to-module mapping).
• target "<name>" { ... } — buildable unit (kind, entry; entry optional for Lib targets).
• dependency "<name>" { ... } — edge in the dependency graph (source, plus provider fields).

Corelib symbols are not prelude-injected; add explicit use imports for modules you need. Host projects still resolve corelib on the dependency graph by default.

Provider behavior

Path dependencies materialize a local project. Registry dependencies download and materialize an active .bpk version. Git dependencies are parsed but are not materialized by the current workflow. An active Git dependency stops the command before compilation.

Use Dependencies and locks for the verified procedure and the registry fallback limitation.

Validation expectations

Exactly one named root block (kind equals name), at least one target, unique labels, entries resolvable under project.root where required. Details: manifest reference and project manifest contract.

Next

Targets and outputs