feat: in-memory generator context seam (fix OpenAPI/AsyncAPI in-memory drift)

[ALagoni97]

Why

In-memory code generation is already a first-class capability of this package — the browser bundle (src/browser/generate.ts, the website playground) generates from an in-memory spec string, and loadAsyncapiFromMemory / loadJsonSchemaFromMemory already existed. The problem: every in-memory caller (the browser bundle, and any programmatic consumer) re-implemented document loading by hand instead of reusing one path, so they silently drifted from codegen generate. Two real drifts found:

1. OpenAPI — in-memory paths dereferenced but never called reflectComponentSchemaNames (the fix(openapi): preserve component schema names through dereferencing #416 fix), so an array of $ref items lost the component name and generated items: ItemsItem[] instead of items: TransactionModel[].
2. AsyncAPI — in-memory callers used a bare Parser without the shared schema parsers (Avro/OpenAPI/RAML/Protobuf) and with looser diagnostics than loadAsyncapiDocument.

What

Make in-memory generation a single, shared path rather than something each consumer re-derives:

• loadOpenapiFromMemory(specString) — shares the exact dereference + reflectComponentSchemaNames normalization with the local-file branch of loadOpenapiDocument.
• realizeInMemoryGeneratorContext({ configuration, specificationDocument }) — the in-memory counterpart of the already-public realizeGeneratorContext; realizes config and dispatches to load{Openapi,Asyncapi,JsonSchema}FromMemory on inputType, using the same root-level virtual paths as the browser path.
• loadJsonSchemaFromMemory now also accepts a raw spec string (backward compatible with the object form).
• Export the seam + the three in-memory loaders from the package entry (src/index.ts).
• src/browser/generate.ts now routes OpenAPI and JSON Schema through the shared loadOpenapiFromMemory / loadJsonSchemaFromMemory instead of its own hand-rolled parse — deleting the duplicated OpenAPI parse (which had the same ItemsItem bug) and JSON Schema parse.
• Ignore the local-only playground/ harness in eslint (mirrors .gitignore).

Why this belongs in the CLI (not a downstream-only hook)

Anticipating the fair question "is this just for an external consumer?" — no:

• This package is explicitly a library as well as a binary (CLAUDE.md: "CLI and library live in the same package under src/"). It already exports realizeConfiguration, runGenerators, realizeGeneratorContext, and the loaders. realizeInMemoryGeneratorContext simply completes that surface as the in-memory twin of the existing public realizeGeneratorContext.
• In-memory generation is an existing CLI feature, not a new one. The browser bundle/playground already does it — and was carrying the same ItemsItem bug. This PR fixes that bug and removes the browser's duplicated parsing.
• The shared loaders now have two independent in-CLI consumers — the browser bundle (src/browser/generate.ts) and the Node in-memory seam (realizeInMemoryGeneratorContext). This is a de-duplication of logic the CLI already had in three places, not scaffolding for one caller.
• The alternative is worse. Leaving each caller to assemble the context from raw loaders is exactly the pattern that produced both drifts here (the inputType→loader dispatch and the missing reflectComponentSchemaNames). Centralizing it is the fix.

Deliberate asymmetry (documented, not an oversight)

The browser's AsyncAPI path stays on loadAsyncapiFromMemoryBrowser rather than the shared seam. The Node loadAsyncapiFromMemory depends on @asyncapi/parser plus the Avro/OpenAPI/RAML/Protobuf schema parsers, which the browser build intentionally shims away for bundle size/compat. OpenAPI and JSON Schema have no such constraint, so those are shared. The seam itself is Node-side (mirroring the Node-only realizeGeneratorContext); the browser assembles its own context because it must inject a browser-shimmed AsyncAPI parser and drives renderGraph directly.

Testing

• npm run build, npm run build:browser, and npm run lint all clean.
• Full npm test: 656 passed, 78 snapshots.
• Verified end-to-end: the safepay OpenAPI example now generates items?: TransactionModel[] (was ItemsItem[]).
• Backward compatibility: loadJsonSchemaFromMemory still accepts the object form (existing browser/tests unchanged).

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
the-codegen-project	Ready	Preview, Comment	Jul 16, 2026 11:23am
the-codegen-project-mcp	Ready	Preview, Comment	Jul 16, 2026 11:23am

[jonaslagoni]

🎉 This PR is included in version 0.77.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀