Fix/record mapped type schemas

[mathpirate]

Not ready for review

Builds on fix/detect-actual-default-exports

---

Summary by cubic

Fix schema generation for mapped types (Record and inline mapped types) and correct default-export detection in the runner to prevent invalid re-exports and permissive schemas.

• Bug Fixes

  • Resolve mapped type property types via checker.getPropertyOfType/getTypeOfSymbol; no more any/true in schemas.
  • Keep TS lib mapped types (Record, Partial, Pick, Required, etc.) inlined by detecting lib.*.d.ts origins; no $defs hoisting.
  • Parse AST to detect real default exports in the runner (export default and export { ... as default }).
  • Add tests and fixtures for Record<union, T>, inline mapped types, Partial/Pick/Required, and nested Record.

• Dependencies

  • Add typescript to packages/runner imports and lockfile.

[cubic-dev-ai]

1 issue found across 9 files

Prompt for AI agents (all 1 issues)

Understand the root cause of the following 1 issues and fix them.


<file name="packages/runner/src/harness/engine.ts">

<violation number="1" location="packages/runner/src/harness/engine.ts:257">
hasDefaultExport misses default-exported function/class declarations, so files with `export default function` lose their default export when re-mapped and Engine.run fails.</violation>
</file>

_{React with 👍 or 👎 to teach cubic. Mention @cubic-dev-ai to give feedback, ask questions, or re-run the review.}

[cubic-dev-ai]

hasDefaultExport misses default-exported function/class declarations, so files with export default function lose their default export when re-mapped and Engine.run fails.

Prompt for AI agents

Address the following comment on packages/runner/src/harness/engine.ts at line 257:

<comment>hasDefaultExport misses default-exported function/class declarations, so files with `export default function` lose their default export when re-mapped and Engine.run fails.</comment>

<file context>
@@ -251,6 +252,36 @@ function computeId(program: Program): string {
 
+// Checks if a source file has a default export by parsing its AST.
+// Detects both `export default ...` and `export { ... as default }` patterns.
+function hasDefaultExport(source: Source): boolean {
+  const sourceFile = ts.createSourceFile(
+    source.name,
</file context>

✅ Addressed in 5f0a842

[ubik2]

I'm curious if we should have "additionalProperties": false on these. In the TypeScript world, we don't let you assign an object with extra properties to these.

Edit: this isn't meant to be something that should be changed -- just not sure what the best behavior is.

[mathpirate]

this was a cool question that caused me to learn some things about typescript, thank you :)

here's an amalgamation of some inputs from claude that make sense to me as a set of takeaways:

Arguments for "additionalProperties": false:

• Stricter validation matches TypeScript's intent
• Catches accidental extra properties (typos, outdated fields)
• More defensive/explicit about the contract

Arguments against (current behavior):

• TypeScript's excess property checking only applies to object literals in direct assignments

 type Settings = Record<"theme" | "language", string>;
 const valid: Settings = { theme: "dark", language: "en" };           // ✓
 const extra: Settings = { theme: "dark", language: "en", foo: "x" }; // ✗ TypeScript error
 // ...but this is valid TypeScript:
 const obj = { theme: "dark", language: "en", foo: "x" };
 const settings: Settings = obj; // ✓ No error! TypeScript's structural typing

• JSON Schema is often used for runtime validation where data comes from external sources
• Being more permissive at runtime matches TypeScript's structural nature
• The schema generator has been following a pattern of only adding additionalProperties: false when TypeScript explicitly forbids extra properties (not just excess
  property checking)

What do you think the validation use case is here? Are these schemas primarily for:

• Type validation at API boundaries (stricter might be better)
• Internal type checking (current behavior is fine)

[mathpirate]

merging this for now but happy to keep chatting about this topic and can easily make whatever changes we decide on in a follow-up!