beskid mod CLI

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

Mods ship like other Beskid packages—manifest, graph, lockfile—but consumers only load them if AOT output exists for the active target.

Workflow sketch

1. Create or open a type: Mod project (Project manifest).
2. Implement public types satisfying SDK contracts (Collector, Generator, …).
3. Run beskid mod rebuild for the target triple that downstream compiles need.
4. Add the mod package to app/lib dependencies; host discovers exports at mod.load.

See the beskid mod command reference for project, target, lockfile, clean, and progress flags.

Artifacts

Normative contract: AOT artifact contract.

Expect:

• Native object for the triple
• mod.descriptor.json (or equivalent export table) listing contract entrypoints

Missing artifact for the requested triple → fail closed, not “skip mod silently.”

Testing mods

• Unit-test Beskid logic in test items where possible.
• Platform behavior locks live in focused beskid_tests_* crates with spec updates (Conformance).

Next

Pipeline phases