Module project 

Multi-file project compilation (v0.3 §3.2 and §3.3, v0.4 §3.5).

A “project” is a directory tree of .bynk source files. The dotted name of a commons or context (e.g., bynk.time, commerce.orders) maps to a path under the project root — either a single file (bynk/time.bynk) or a directory of files all sharing the same header (bynk/time/*.bynk).

v0.4: each file is one of two kinds — commons or context. Both kinds share the same multi-file directory machinery; they differ in body content (contexts have consumes/exports, types are nominally per-context), in visibility (contexts export only the types listed), and in TypeScript emission (contexts re-brand types from used commons).

Compilation proceeds in two passes:

1. Discover and parse every .bynk file. Group by qualified name and kind. Build a global symbol table where each unit contributes its declarations.
2. Resolve, type-check, and emit each unit with full visibility of the units it transitively uses or consumes. Two passes keep uses cycles trivial — there is no order-of-evaluation, only declarative mixin.

Structs

AgentDepsPlan

#527: the DO-side deps plan for one workers context. Capability providers cannot cross the DO wire ({ args, deps } is JSON — a provider’s methods die in serialisation), so the generated Durable Object reconstructs its agents’ given deps inside the DO from the same wiring compose uses.

AttributedError

v0.24 (ADR 0052): a compile error attributed — where possible — to the project-relative source file it belongs to, tagged at the collection point (the phase that produced it knows which file it was processing). None is the project-level bucket: validations spanning files (group/cycle/directory consistency) with no single owning file.

CompileOptions

Options for compile_project. Construct with CompileOptions::single or CompileOptions::split, then chain .target(…) / .platform(…) / .import_ext(…) to override the bundle/default-platform/.js defaults.

CompiledFile

One generated TypeScript file.

ContextBoundaryInfo

#855: the per-unit slice of resolution the wire-contract peek needs — see ProjectAnalysis::boundary_info. A sibling of ContextSequenceInfo, not a field on it: that struct is named and documented for #846, and this is a separate retained table serving a separate query (hover/panel over a single handler’s boundary, not the sequence-diagram classifier). Moved verbatim (Decision C, #1115).

ContextSequenceInfo

#846: the per-unit slice of resolution the sequence-diagram classifier needs — see ProjectAnalysis::sequence_info. Moved verbatim (Decision C, #1115) from bynk-emit/src/project/diagnostics.rs.

DiscoveredCase

One discovered test "<name>" case. location points at the case-name literal (a run failure instead points at the failing assert), giving the editor click-through to the declaration before any run.

DiscoveredSuite

v0.67: a discovered test suite — one test <target> group (unit) or test integration "<suite>" (integration). name + kind mirror exactly what the NDJSON runner emits at suite-begin (kind "unit" carries the joined target name; "integration" carries the bare suite name), so the editor reconciles discovery and run documents to the same tree items.

FileDeclIndex

For each name declared in the unit (type, fn, method), record which source file declared it. Used by the emitter to render relative imports.

InMemoryAnalysis

The outcome of analyse_in_memory_with_types: diagnostics plus the analysed file’s (span, type) entries (span-sorted — see ExprTypeSink::take_files), for a position→type query (#397, the playground’s hover), and its local bindings (#808, the playground’s completion — bynk_check::locals::locals_at over locals answers “what’s in scope at this offset”).

ProjectAnalysis

v0.24: the analyse-mode result — every discovered file’s analysed text snapshot (positions must convert against the text that was analysed, not a newer buffer) plus the attributed diagnostics. Moved verbatim (Decision C, #1115) from bynk-emit/src/project/diagnostics.rs; bynk-emit re-exports this type at its old path (bynk_emit::project::ProjectAnalysis) so bynk-ide’s existing destructuring needs no field-by-field rewrite.

ProjectCheck

Result of check_project: every diagnostic from a non-bailing project analysis — errors and warnings together (ADR 0117), unconditionally, unlike ProjectOutput/ProjectFailure where errors/warnings is picked by which variant the caller got. bynk check’s exit code is decided by Self::has_errors, not by whether this was reached at all.

ProjectFailure

v0.24: a failed build with its attribution and snapshots intact — what the CLI renders rich (ariadne source context per file); the plain compile_project* wrappers flatten it to the pre-v0.24 error list.

ProjectOutput

Result of compiling a project.

ProjectPaths

v0.113 (DECISION S): the project’s source tree, read from bynk.toml’s [paths] section. Test-ness is a property of the suite declaration, not of a directory, so the layout is a flat include list of trees to compile and an exclude list of subtrees to skip — not the role-named src/tests split. Each include entry is a root walked for .bynk files; a file’s identity path is relative to the include root that contains it.

TestLocation

A project-root-relative path:line:col source location, structured. Line and col are 1-indexed (the bynk_syntax::span::line_col convention).

UnitTable

Combined symbol tables for a single logical commons or context.

Enums

BuildTarget

The build target. Determines how cross-context calls and per-context modules are emitted (v0.8). Bundle mode is the default — all contexts emit into one TypeScript bundle and cross-context calls are direct function invocations. Workers mode produces per-context Cloudflare Worker bundles that communicate via Service Bindings.

ImportExt

The extension emitted import specifiers use (import … from "./x.<ext>").

ProjectPathsError

A problem in bynk.toml that try_read_project_paths surfaces instead of silently falling back to the conventional layout.

Roots

Where a project’s .bynk files live.

SchemaLock

bynk-emit’s CompileOptions::schema_registry value — whether a build reconciles bynk.schema.lock, and if so, its current content.

UnitKind

Distinguishes a commons from a context (and from a test) in the project graph. Tests are a third kind in v0.7.

Functions

analyse_in_memory

Analyse a single in-memory Bynk source and return all diagnostics — non-bailing, no emission (in-browser track, slice 5d). The editor calls this on every (debounced) keystroke for live diagnostics: unlike compile_in_memory (build mode, which bails at the first failing phase), this runs in Analyse mode, so parse / resolve / check diagnostics are recovered and reported together — and it works for a context (the playground’s typical program), not only a commons. Same fs-free seam as compile_in_memory.

analyse_in_memory_with_types

Like analyse_in_memory, but also exposes the expression-type map the checker captured (ADR 0063’s expr_types sink) — the same one analyse_project_with drains — instead of discarding it. Per ADR 0094, this is a best-effort partial map in Analyse mode: a function that type-checked cleanly contributes its types even if a different function in the same file has an error, so expr_types is empty only when the expression at hand never typed at all (e.g. it sits in an unresolved region, ADR 0094’s “out of scope — the resolve gate”), not merely because the file has some error somewhere.

analyse_project

v0.24: analyse a project without building — non-bailing, overlay-aware, file-attributed (ADR 0052). overlay maps canonicalised absolute paths to buffer text layered over disk reads (unsaved editor buffers).

analyse_project_with

Slice A: analyse a project whose roots are resolved from its manifest — the same Roots compile_project consumes, resolved the same way, so the LSP discovers exactly the files bynkc compiles.

check_project

Check a project without building (finding #64) — never bails after discovery (Mode::Analyse, the same mode analyse_project_with already uses for the editor), so a diagnostic anywhere in the project does not suppress diagnostics elsewhere. compile_project’s Mode::Build bails at the first structural error and returns only what it collected up to that point — correct for build/test, which must not emit past a real error, but wrong for check, whose only job is to report everything. bynk check’s directory path calls this instead of compile_project.

compile_in_memory

Compile a single in-memory Bynk source through the full project pipeline — no filesystem access (in-browser track, slice 3). The source is the in-process Bundle subset that consumes bynk; first-party injection and the per-platform binding emission run exactly as for an on-disk build, so the returned ProjectOutput is the complete module graph (the user unit + runtime.ts + the bynk-<platform>.ts binding + compose.ts). The wasm entry point pairs this with bynk-strip to produce JavaScript for the playground.

compile_project

Compile a Bynk project, keeping error attribution + snapshots on failure (so the CLI can render project errors with source context, ADR 0052). Use .map_err(ProjectFailure::flatten) for the flattened Vec<CompileError> shape.

discover_project_files

Slice A: the .bynk files these roots contain — the same walk compile_project performs, honouring exclude and the tool’s own out/ node_modules caches.

try_read_project_paths

Read bynk.toml’s [paths] section, surfacing a malformed manifest — a parse failure or an unrecognised [paths] key — as an error instead of silently falling back to the conventional layout (the previous read_project_paths total form’s behaviour, R3.8 — deleted in favour of this at all 18 of its callers, #1113).

try_read_project_paths_with

Like try_read_project_paths, but honours overlay for bynk.toml itself, the same way discovery::read_source does for every other file.

worker_dir_name

v0.8: directory name of a Worker for a given context, with dots replaced by dashes (commerce.payment → commerce-payment).

worker_handlers_output_path

v0.8: project-relative output path of the workers-mode handlers file.

worker_handlers_source_path

v0.8: project-relative synthetic source path of the workers-mode handlers file for a given context. Used so the emitter’s relative-import machinery resolves correctly against the workers layout.