TypeScript CLI has no `libraries` key, so `meta gen` cannot load a shipped library the registered generators consume

[dmealing]

What

libraries exists only on MetaDataLoader.fromDirectory in the TypeScript port. The CLI never passes it and no flag or config key exposes it, so meta gen / meta verify cannot load metaobjects::ai::LlmCallBase.

The generators that consume it are registered for the CLI, so the generator is reachable from the command line while its input is not.

Evidence (against main @ 0994d6e41)

$ git grep -l "libraries" main -- 'server/typescript/packages/cli/**'
(no output)

librarySources is wired only at server/typescript/packages/metadata/src/loader/meta-data-loader.ts (the fromDirectory factory).

Why it matters

Programmatic consumers can opt in; anyone driving the toolchain the documented way — metaobjects gen ./metadata --out ./generated — cannot. An adopter's extends: metaobjects::ai::LlmCallBase fails with ERR_UNRESOLVED_SUPER through the CLI even though the identical model loads fine through the API.

Suggested shape

The Python port just took a libraries key on the project config and threaded it into its single load path, alongside the existing providers key — that is probably the closest analogue here, since metaobjects.config.ts already carries providers.

One design point worth keeping if you follow it: on Python an unknown package name is a hard config error naming the valid ones, while the programmatic API keeps the silent skip. A name a human typed into a config file is a mistake worth failing on; an API caller asking for a package that version does not ship should still be able to load its own metadata. Skipping silently in the config case resurfaces later as ERR_UNRESOLVED_SUPER pointing at the adopter's own metadata — the wrong place to go looking.

Related

• Java is missing the whole feature (generator present, no loader option at all) — filed separately.

[dmealing]

Fixed on main — metaobjects.config.ts takes libraries?: readonly string[], beside providers as you suggested, since it answers the same shape of question: what does this project's model need in scope beyond the files it declares.

The design point you flagged is kept exactly: an unknown name in the config is a hard error naming the valid ones, while librarySources keeps the silent skip for the programmatic API. Same reasoning you gave — skipped, it resurfaces as ERR_UNRESOLVED_SUPER pointing at the adopter's own metadata, the wrong place to go looking.

Threaded to loadMemory at 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, since providers reached every command and libraries reached none.

librarySources is reached through a new @metaobjectsdev/metadata/library subpath, imported lazily, never from the root barrel: it reads node:fs, and a root-reachable static import drags Node built-ins into every consumer's graph, which is #287. Gated by a positive arm, a negative arm (without the key the same model must still fail), and an unknown-name arm.