You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 6d8e95d
Browse filesBrowse the repository at this point in the historyBrowse files
feat(cli): a libraries key, so a shipped library is loadable through the toolchain (#333)
`librarySources` was reachable only from `MetaDataLoader.fromDirectory`. No CLI command
uses that factory — every one of them goes through `loadMemory` with a resolved file list
— so `libraries` existed on the loader and reached nothing. The generators that consume a
library ARE registered for the CLI, which is the sharp edge: the generator was reachable
from the command line while its input was not, and an adopter following the documented
`extends: "metaobjects::ai::LlmCallBase"` path got ERR_UNRESOLVED_SUPER pointing at their
own metadata.
`metaobjects.config.ts` gains `libraries?: readonly string[]`, beside `providers` because
it answers the same shape of question — what does this project's model need in scope
beyond the files it declares. Python took the same key on its project config, and the two
ports agreeing on the name and the semantics is the point.
Threaded to `loadMemory` by all eight load sites (gen, verify, docs, prompt-snapshot, and
migrate's four) through one `loadMemoryOptionsFrom` helper rather than a spread pair
copied eight times. That is the actual lesson of this bug: `providers` reached every
command and `libraries` reached none, so the fix that leaves eight independent
opportunities to thread one and forget the other has not fixed the class.
Design points worth keeping:
- Opt-in, never automatic. A library package registers real top-level nodes, and a project
that never references one should not find them in its model, its generated output or its
docs. The negative test arm exists for this: without the key the same model must still
fail to load. A positive-only test keeps passing if the load is quietly made
unconditional, which is exactly the regression that would matter.
- An unknown name is a HARD config error naming the available packages, while
`librarySources` keeps skipping one silently for a programmatic caller. An API caller
asking for a package this version does not ship should still be able to load its own
metadata; a name a human typed into a config file is a mistake worth failing on, because
skipped it resurfaces later as ERR_UNRESOLVED_SUPER against the adopter's OWN metadata —
the wrong place to send someone looking. Python draws the same line in the same place.
- `librarySources` is imported lazily through a new `@metaobjectsdev/metadata/library`
subpath, never from the root barrel. It reads `node:fs`, and a root-reachable static
import drags Node built-ins into every consumer's module graph — the #287 bundle defect.
The subpath exists for exactly the reason `./constants` does.
- Library sources are PREPENDED, matching `fromDirectory`. Super resolution is
order-independent, so this is determinism rather than correctness.
`knownLibraryPackages()` is new, so the config validator can say what IS available instead
of only what is not.
cli: 630 pass / 3 skip / 0 fail. sdk: 278 pass / 0 fail. The help snapshot moved because
`meta docs`' `<metadata>` line now states that passing it scopes the run (#327).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
0 commit comments