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_document;

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

display_path

#1772: the path a diagnostic names, as a user would type it from the working directory: the build’s root as the caller spelled it, joined with the file’s identity path (relative to that root). A relative root is already relative to the working directory; an absolute one (bynk dev resolves the project root) is shown relative to the working directory when it lies inside it. This matches the path fmt reports for the same file, so a problem matcher resolving against the working directory finds it. Separators print as / on every platform.

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.

project_source_files

The .bynk files try_project_options reads for the directory input, sorted: what check, test and compile see. #1753: fmt expands a directory argument through this, so fmt --check <dir> and check <dir> cover the same files.

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.