Members
The buildable things in a workspace, where their content comes from, and how they refer to each other.
A member is one buildable thing. It has a name, a source, and usually a
.bldr.ts saying what it produces.
Four kinds of source
Whatever the kind, what a build sees is content addressed by hash.
| Kind | Declared as | Content is |
|---|---|---|
| Local path | name: members/thing | whatever that directory holds at build time |
| Container image | kind: container-registry | the image's root filesystem |
| Git repository | kind: git | the tree at a commit |
| Object storage | kind: s3 | the object |
A local path is the common case and the simplest: no pin, no tracking, just the directory. The others pin an exact version and optionally record where a newer one would come from.
A local member is read the way git reads that directory. Everything your
.gitignore excludes is never walked, hashed or stored, so a stale target/
or node_modules/ costs nothing. Put a .bldrignore beside a directory to
override that where you need something git hides.
Names are the dependency edges
A member's .bldr.ts refers to other members by name, and those imports are
the build graph:
import nodeImage from "node"; // a tracked base image
import { pkg as designSystem } from "bldr/ui"; // another member's outputNothing declares the edges separately, so they cannot drift from the code. If
your member imports node, then node is a dependency of your member, because
that is what the import means.
Two things are already in scope in a .bldr.ts and are not imported:
scope | where this member registers its targets |
member | this member itself, notably member.rootDirectory |
Naming
Members owned by the workspace are conventionally named with a prefix, such as
bldr/cli and bldr/ui, while tracked upstream content keeps its own name:
node, rust, debian. It reads well and it makes clear which things you
control.
Rename before a member has been built much. Cache volume names derive from the member name, so a rename starts those caches cold.