Bugfix: Build fails with TS1205: Re-exporting a type when 'isolatedM...

Documentation for Sessions

🐛 Bugfix: Build fails with TS1205: Re-exporting a type when 'isolatedM...

Date: 2026-02-21
Time: 22:03:12 UTC
Session: gspace1-133.21
Agent: angular
Confidence: 99%
Status: ✅ Documented

📋 Decision Context

Question:

Build fails with TS1205: Re-exporting a type when 'isolatedModules' is enabled — ChatPlugin (an interface) re-exported alongside isChatPlugin (a runtime function) in a single export statement in plugins/index.ts.

Task: Fix TS1205 isolatedModules build error in vitto-chat plugins barrel export

🎯 Decision Made

Chosen:

Use 'export type { ChatPlugin }' separately from 'export { isChatPlugin }'

Options Considered:

  1. Use 'export type { ChatPlugin }' separately from 'export { isChatPlugin }'
  2. Change ChatPlugin from interface to class to make it a runtime value
  3. Disable isolatedModules in tsconfig
  4. Use inline export in the source file and remove the barrel re-export

💭 Reasoning

ROOT CAUSE: TypeScript's isolatedModules flag requires type-only exports to use 'export type' syntax because the compiler must be able to erase type imports per-file without cross-file analysis. ChatPlugin is an interface (type-only, erased at runtime) but was re-exported alongside isChatPlugin (a runtime function) using a single 'export { ChatPlugin, isChatPlugin }' statement. The compiler cannot determine ChatPlugin is type-only from the re-export alone. FIX: Split into 'export type { ChatPlugin }' and 'export { isChatPlugin }'. This is the canonical TypeScript solution — it preserves the barrel export pattern, requires zero changes to consumers, and correctly signals the compiler's erasure semantics. Disabling isolatedModules is not viable (Angular compiler requires it). Changing interface to class adds unnecessary runtime overhead. Removing barrel exports breaks the public API.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation