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.
#2207 (packaging slice 1): the map tables, each with the keys one of
its entries accepts. A map table’s own keys are names the user chooses
(dependency aliases, registry names), checked against decision G’s grammar;
each entry is a table of fixed keys, refused with did-you-mean like
MANIFEST_TABLES’ keys are.
#1665: the tables bynk.toml may hold, each with the keys it accepts.
[fmt]’s keys are bynk-fmt’s to check (FmtConfig, deny_unknown_fields),
so its list here is empty and unchecked.
#1665: check bynk.toml’s table set and the keys of [project] and
[lsp] (MANIFEST_TABLES). Every other reader takes only its own table
and ignores the rest, so an unknown table ([dependencies], a typo’d
[pahts]) used to build cleanly with none of its intended behaviour.
The path a unit’s name maps to, relative to a source or output root:
a.b is a/b. A dependency’s canonical unit name (#2223,
crate::packages::PackageId::encoded) maps under
deps/<org>/<package>/, so every name-to-path site lays a dependency’s
units out there without knowing about packages.
#1890: the bynk.project.duplicate_compatibility_flag warning for one
flag [workers] compatibility_flags repeats, against manifest (the
project’s bynk.toml). default says the repeat is of a flag every
Worker already has, rather than of an earlier entry in the list. Built
here, with the manifest’s other diagnostics, rather than in bynk-emit,
which only finds the duplicate while merging the list (R3.5 keeps
diagnostics out of emission).
v0.17 [DECISION L] stub: a version range is unpinned — and rejected — when
it is empty, */x/latest, or otherwise carries no concrete version
number. A pinned range names at least one digit (^5, ~1.2, 1.2.3,
>=1.0 <2). No allow-list or registry check yet.
Normalise a relative path by resolving . and .. components, so a binding
clause like ./tokens.binding.ts beside src/tokens.bynk yields the output
path tokens.binding.ts.
The project’s [unstable] table as both the build and the editor see it
(#1963 Decision E): the overlay’s bynk.toml when it holds one (the LSP puts
the open buffer there), otherwise the one on disk (a CLI build’s overlay holds
only .bynk sources). A missing or malformed manifest reads as empty; its
shape errors are check_manifest’s to report.
#302: the qualified name a file moved from old_rel to new_rel should now
declare, preserving whichever unit_path_matches arrangement old_rel
used to satisfy against old_name — the dotted stem for a single-file
unit, or the dotted parent-directory for one file of a multi-file unit.
Returns None if old_rel/old_name don’t actually satisfy either
arrangement (a pre-existing inconsistency the caller should not guess at).
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).
Read bynk.toml’s [workers] table, honouring overlay for bynk.toml
the way try_read_project_paths_with does. No manifest, or no
[workers] table, is the empty WorkersConfig. A manifest that doesn’t
parse is ProjectPathsError::Malformed, and a compatibility_flags
that isn’t a list of strings is ProjectPathsError::NotAStringList. The
shape is checked here as well as in check_manifest, because some
callers (the e2e harness) read the table without the whole-manifest check.
#1820: project-relative synthetic source path of one file’s module in a
context split across files, on Workers. Each file is its own module under
workers/<dir>/handlers/, and handlers.ts re-exports them all, so the
Worker’s entry point and composition root, and every consumer, still
import the context from handlers.ts. A file keeps its stem
(shop/orders/place.bynk → handlers/place.bynk). Distinct files map to
distinct modules because every file of a split unit sits directly in its
<name>/ directory: a <name>.bynk beside it is rejected
(bynk.project.file_and_directory), as is a file in any other directory
(bynk.project.inconsistent_commons_name). The emitted module is
ts_output_path of this 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.