Crate bynk_driver 

bynk-driver — the shared front-end of the bynkc and bynk CLIs (#521).

Both binaries expose fmt and check with identical semantics; before this crate each re-implemented the command bodies (and the project-failure flattening layer, and the project-rooting rule) as by-hand copies pinned only by comments and a skip-able parity test. The single implementation lives here, parameterised by the program name that prefixes messages.

Re-exports

pub use output::write_compiled_file;

pub use output::write_output;

Modules

coverage

bynkc test --coverage — remap V8 line coverage onto .bynk source.

discovery

Walking a directory tree for .bynk files and reading them — the driver’s side of CompileOptions.sources (#1077, R2.3/T0.7 residue).

output

Writing a compiled project’s output to disk.

probe

The shared detection probe: presence + version + provenance.

schema_lock

Reading and atomically writing bynk.schema.lock — the driver’s side of CompileOptions::schema_registry (#1078, R2.3/T0.7 residue).

test_json

v0.59: the bynkc test --format json result model, plus the parser that folds the runner’s NDJSON event stream into it.

test_runner

bynkc test / bynk test’s shared command body (Wave 5 §5.4, findings #40/#72/#20/#21 remainder): compile the project’s test declarations, write them, and run them via tsc → node (falling back to tsx), folding the result into the pinned crate::test_json::TestRun document in --format json mode. Moved down from bynkc — both bynkc and bynk need one implementation instead of two.

Structs

FmtArgs

The fmt subcommand’s arguments, flattened by both bynkc::cli and bynk::cli so the two spell one contract rather than two copies of it (the test_runner::TestArgs pattern, findings #40/#72). Field docs here are the CLI help text for both commands’ flags.

Enums

IndentKind

How --indent spells the two IndentStyle variants. The words match the [fmt] indent key in bynk.toml, which the language server already reads, so a project states the same choice the same way in either place.

ProjectOptionsError

Why try_project_options could not produce a usable CompileOptions: either the manifest itself is unreadable (ProjectPathsError), or a well-formed manifest names a project tree that can’t be walked (discovery::DiscoveryError) — #1081 review.

Functions

print_project_check

Render every diagnostic from a project::ProjectCheck (finding #64) with the same per-file ariadne context print_project_failure gives its own, errors-only list. Unlike that renderer, a ProjectCheck’s list can legitimately mix both severities — the unattributed fallback line names its actual severity (bynk_render::severity_word) rather than print_project_failure’s bare [category]: message (silently correct only because that list is errors-only by construction).

print_project_check_short

print_project_check via project_check_short_lines.

print_project_failure

Render a project build failure with per-file ariadne context, exactly as single-file mode had rich rendering. Unattributed (project-level) errors keep the plain form.

print_project_failure_short

The project-failure analogue of bynk_render::print_errors_short: each attributed error is positioned against its file’s snapshot; an unattributed (project-level) error falls back to <severity>[<category>]: <message>.

print_project_warnings

v0.89 (ADR 0117): print a successful build’s non-failing warnings, with real per-file ariadne context now that a successful build’s snapshots (mirroring ProjectFailure::snapshots) make that possible. A warning whose source isn’t attributable (or doesn’t fit the snapshot) falls back to the plain warning[<category>]: <message> form.

print_project_warnings_short

print_project_warnings’s --format short analogue: one path:line:col: warning[category]: message line per warning, falling back to warning[category]: message when unattributed. Strictly one line per warning throughout (like bynk_render::render_errors_short, this mirrors the VS Code problem-matcher’s contract), so — unlike print_project_warnings — finding #47 doesn’t reach this one.

project_check_short_lines

print_project_check’s --format short analogue, mirroring project_failure_short_lines.

project_failure_short_lines

The string form of print_project_failure_short: one path:line:col: severity[category]: message line per attributed error (an unattributed project-level error falls back to severity[category]: message). Backs both the printer above and the bynkc test --format json compile-error document, whose diagnostics the VS Code bynkc problem-matcher re-parses — each Vec entry is exactly one line by that contract, so unlike the other renderers in this file this one deliberately does not grow note/label continuation lines (finding #47): doing so would break a machine consumer that re-parses every entry as a single diagnostic line.

project_options

Root a directory project the way every project command should (#46): a bynk.toml or a src/ subdir selects project mode, whose flat [paths] include/exclude layout (v0.113, DECISION S) defaults to the conventional roots that exist (src, tests) or the project root itself; otherwise the legacy single-tree where <dir> is itself the root. check, compile, test, and dev all route through this so the conventional layout works the same from any of them.

run_check

The check command body shared by bynkc check and bynk check: a directory routes through project::check_project (finding #64 — non-bailing, so a structural error anywhere does not hide diagnostics elsewhere the way compile_project’s bail-fast Mode::Build would), a single file through bynk_emit::compile_with_warnings. short selects the one-line --format short rendering. prog prefixes messages (bynk: …).

run_fmt

The fmt command body shared by bynkc fmt and bynk fmt: each input is formatted and rewritten only when it changes; --check reports non-canonical files without writing; - reads stdin and writes the formatted result to stdout. prog prefixes messages (bynk fmt: …).

try_project_options

project_options, but a malformed bynk.toml is an error rather than a silent fall-back to the conventional layout — the one input a user hand-edits that the compiler otherwise reads without checking, after which a cascade of bynk.uses.unknown_target errors points at units that plainly exist on disk.