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

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.

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.

EmitProjectCtx

Context passed to the emitter so it can resolve cross-file and cross-unit references into TypeScript import statements.

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.

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.

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

BoundaryOwner

Where a boundary-crossing type was declared.

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>").

Roots

Where a project’s .bynk files live.

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_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).

check_function_type_boundary_items

Item-level body of the boundary confinement, shared with the single-file (legacy) compile path in bynkc’s lib.rs.

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.

read_project_paths

v0.113: read bynk.toml from project_root. Returns the conventional layout (see ProjectPaths::conventional) if the file is missing or declares no [paths] include. Honours include / exclude under [paths], each an array of path strings; anything else is ignored. A minimal hand-rolled TOML reader — we only need string and string-array values here.

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.