builder.io 1.6.94 → 1.6.96

package/types/cli/codegen.d.ts

@@ -15,6 +15,7 @@ export interface SessionContext {
     beforeCommit: string | undefined;
     createdUnixTime: number;
     updatedUnixTime: number;
+    canLoadMore: boolean;
 }
 export interface CodeGenSessionOptionsBase {
     sys: DevToolsSys;
@@ -45,6 +46,19 @@ export declare class CodeGenSession {
     constructor(options: CodeGenSessionOptions);
     get workingDirectory(): string;
     initializeSession(): Promise<void>;
+    loadWholeSession(opts?: {
+        linear?: boolean;
+        getAll?: boolean;
+    }): Promise<{
+        sessionId: string;
+        title: string | undefined;
+        beforeCommit: string | undefined;
+        createdUnixTime: number;
+        updatedUnixTime: number;
+        addedTurns: number;
+        turns: CodegenTurn[];
+    }>;
+    loadMoreTurns(): Promise<CodegenTurn[]>;
     setRepoUrl(repoUrl: string): void;
     getRepoUrl(): string | undefined;
     setPrUrl(prUrl: string): void;
@@ -156,6 +170,7 @@ export declare class CodeGenSession {
     };
     sendFeedback(feedback: Partial<CodegenFeedback>): Promise<void>;
     lastTurnHasChanges(): Promise<boolean>;
+    clearSession(): void;
     sendMessage(message: GenerateUserMessage, immediate?: boolean): Promise<void>;
     getTurns(): CodegenTurn[];
     getSessionContext(): SessionContext;
@@ -171,10 +186,6 @@ export declare class CodeGenSession {
     waitForEventLoop(): Promise<void>;
     agentCompletion(userMessage: GenerateUserMessage, signal: AbortSignal | undefined, onStep: (step: GenerateCompletionStep) => void): Promise<void>;
     commitWorkInProgress(lastTurn: CodegenTurn): Promise<string | undefined>;
-    /**
-     * Returns true if the last turn's afterCommit (or beforeCommit) is different from the session's beforeCommit.
-     */
-    hasChanges(): boolean;
     isCleanWorkTree(): Promise<boolean>;
     /**
      * Resolves a workspace file path to its actual file system path

package/types/cli/index.d.ts

@@ -23,6 +23,12 @@ export interface CLIArgs {
     mappingOutput?: string;
     /** Skip package installation step */
     skipInstallation?: boolean;
+    /** Skip detailed grouping in repo indexing */
+    skipDetailedGrouping?: boolean;
+    /** Skip display of header in repo indexing */
+    skipHeader?: boolean;
+    /** Design system package to use for repo indexing */
+    designSystemPackage?: string;
     /** Token to use for figma */
     token?: string;
     /** Url to start from */
@@ -59,4 +65,6 @@ export interface CLIArgs {
     clearMappings?: boolean;
     /** Enabled tools, list of strings separated by commas */
     enabledTools?: string;
+    /** If true run brief indexing before running code generation */
+    index?: boolean;
 }

package/types/cli/utils/repo-indexing-group-prompts.d.ts

@@ -1 +1 @@
-export declare const REPO_INDEXING_GROUP_PROMPT = "# Component Repository Analysis and Grouping\n\n## Objective\nAnalyze the repository to identify and categorize components based on **mandatory architectural interdependency**, creating groups ONLY when components literally cannot function independently and MUST be used together.\n\n## Component Grouping Philosophy - STRICT CRITERIA\n\n### ONLY Group Components That Meet ALL These Requirements:\n\n1. **Mandatory Compositional Architecture**\n   - Components that literally cannot render or function without their counterparts\n   - Parent components that are meaningless without specific child components\n   - Child components that will throw errors or fail without their required parent\n   - Example: `Table` requires `TableHeader`, `TableBody`, `TableRow`, `TableCell` to be functional\n\n2. **Exclusive Required Context Dependencies**\n   - Components that share context where the context is NOT optional\n   - Child components that will fail without the parent's required context\n   - Components with hard-coded provider-consumer relationships that cannot be bypassed\n   - Example: `FormField` + `FormLabel` + `FormControl` sharing required form context\n\n3. **Critical Runtime Dependencies**\n   - Components that reference each other's internal APIs or state directly\n   - Components that communicate through required internal protocols\n   - Components where removing one breaks the others at runtime\n\n### What MUST REMAIN SEPARATE - Even If They Share Code\n\n**Shared Infrastructure \u2260 Interdependency**\n- AreaChart, BarChart, LineChart are SEPARATE even if they use shared cartesian infrastructure\n- Each chart can render independently without the others\n- Shared internal components are implementation details, not architectural coupling\n\n**Thematic Similarity \u2260 Coupling**  \n- Button, IconButton, ToggleButton stay separate (each works alone)\n- Input, Select, TextArea stay separate (independent form controls)\n- Card, Panel, Modal stay separate (independent containers)\n\n**Optional Composition \u2260 Required Composition**\n- Components that CAN work together but don't HAVE to\n- Components where composition is for convenience, not necessity\n\n## Strict Validation Test\nBefore grouping ANY components, ask these questions. ALL must be \"YES\":\n\n1. **Removal Test**: If I remove one component from this group, do the others become non-functional or throw errors?\n2. **Independence Test**: Can ANY component in this group render successfully in complete isolation?\n3. **Context Test**: Do these components share context that is absolutely required (not optional)?\n4. **API Test**: Do these components directly call each other's methods or access each other's internal state?\n\nIf ANY answer is \"NO\" \u2192 DO NOT GROUP\n\n## Examples of CORRECT Grouping\n\n** Table Group** (Critical Coupling)\n```json\n{\n  \"name\": \"Table\",\n  \"components\": [\"Table\", \"TableHeader\", \"TableBody\", \"TableRow\", \"TableCell\"],\n}\n```\nWhy: Table component cannot render without TableHeader, TableBody, etc. Each piece is meaningless alone.\n\n**Form Field Group** (Strong Coupling)  \n```json\n{\n  \"name\": \"FormField\", \n  \"components\": [\"FormField\", \"FormLabel\", \"FormControl\", \"FormMessage\"]\n}\n```\nWhy: These share required form context and cannot function independently.\n\n## Examples of INCORRECT Grouping\n\n** Charts Group** (Shared Infrastructure \u2260 Coupling)\n```json\n// WRONG - Don't do this\n{\n  \"name\": \"Charts\",\n  \"components\": [\"AreaChart\", \"BarChart\", \"LineChart\", \"PieChart\"]\n}\n```\nWhy: Each chart renders independently. Shared infrastructure is an implementation detail.\n\n** Button Group** (Thematic Similarity \u2260 Coupling)\n```json\n// WRONG - Don't do this  \n{\n  \"name\": \"Buttons\",\n  \"components\": [\"Button\", \"IconButton\", \"ToggleButton\"]\n}\n```\nWhy: Each button type works completely independently.\n\n## Default Assumption: KEEP SEPARATE\n- When in doubt, create separate groups for each component\n- Err on the side of independence rather than grouping\n- Most components should end up in individual groups\n\n## Instructions\n\n### 1. Component Discovery\n- Scan the entire repository for all components\n- Identify component files, their exports, and related files\n\n### 2. Interdependency Analysis\nFor each component, analyze:\n- **Required Dependencies**: What other components MUST be present for this to work?\n- **Context Requirements**: Does this component require specific context providers?\n- **Compositional Rules**: Are there mandatory parent-child relationships?\n- **Shared State**: Do components communicate through shared internal state?\n\n### 3. Coupling Strength Assessment\nEvaluate coupling strength:\n- **Critical Coupling**: Components cannot function without each other\n- **Strong Coupling**: Components are designed to work together with shared context\n- **Moderate Coupling**: Components enhance each other but can work independently\n- **Weak Coupling**: Components are thematically related but functionally independent\n\n### 4. Group Formation Rules\n- **Group together**: Components with Critical or Strong coupling\n- **Consider grouping**: Components with Moderate coupling (case-by-case basis)\n- **Keep separate**: Components with Weak coupling or functional independence\n\n### 5. Relevant Files Collection\nFor each group, include:\n- Primary component files (.tsx, .ts)\n- Context providers or shared state files\n- Type definition files specific to the group\n- Hook files that bind the components together\n- Test files that test the group as a unit\n- Documentation files specific to the group\n- Example files showing the components working together\n\n## Required Output Format\n\nGenerate a component-groups.json file with this structure:\n\n```json\n[\n  {\n    \"name\": \"Table\",\n    \"description\": \"Use this component group to generate components that handle tabular data with required hierarchical structure\",\n    \"components\": [\"Table\", \"TableHeader\", \"TableBody\", \"TableRow\", \"TableCell\"],\n    \"relevantFiles\": [\"table.tsx\", \"table-header.tsx\", \"table-body.tsx\", \"table-row.tsx\", \"table-cell.tsx\", \"table-context.tsx\", \"table.types.ts\"]\n  },\n  {\n    \"name\": \"AreaChart\",\n    \"description\": \"Use this component to generate area chart functionality\",\n    \"components\": [\"AreaChart\"],\n    \"relevantFiles\": [\"src/area-chart/index.tsx\", \"src/area-chart/interfaces.ts\"]\n  },\n  {\n    \"name\": \"BarChart\", \n    \"description\": \"Use this component to generate bar chart functionality\",\n    \"components\": [\"BarChart\"],\n    \"relevantFiles\": [\"src/bar-chart/index.tsx\", \"src/bar-chart/interfaces.ts\"]\n  }\n]\n```\n\n### Coupling Strength Definitions:\n- **\"critical\"**: Components cannot function without each other (Table group)\n- **\"strong\"**: Components share exclusive context/state (Form group)  \n- **\"moderate\"**: Components enhance each other but can work alone (ButtonGroup + Button)\n- **\"none\"**: Component is functionally independent (standalone Button)\n\n## Quality Requirements\n\n**Be Conservative:**\n- Prefer individual component groups over multi-component groups\n- Only group when there's undeniable architectural interdependency\n- Most components should be individual groups\n\n**Component Coverage:**\n- Include ALL components found in the repository\n- Every component must appear in exactly one group\n- Prefer smaller, focused groups over large, loosely-coupled groups\n- Create individual groups for truly independent components\n\n**Grouping Validation:**\nFor each proposed group, ask:\n1. Would removing any component make the others useless or broken?\n2. Is there a required parent-child rendering relationship?\n3. Do they share mandatory (not optional) context or state?\n\nIf you can't answer \"YES\" confidently to at least one of these, keep components separate.\n\n**File Selection:**\n- Include files that are essential to understanding the group's architecture\n- Focus on files that show interdependencies between components\n- Include context providers, shared hooks, and type definitions\n- Exclude generic utility files unless they're group-specific\n\n## Anti-Patterns to Avoid\n\n**Don't group by theme alone**\n- Wrong: Group Button, IconButton, ToggleButton because they're all \"buttons\"\n- Right: Keep them separate because each works independently\n\n**Don't create mega-groups**  \n- Wrong: Group all form-related components together\n- Right: Group only those that share context (FormField + FormLabel + FormControl)\n\n**Don't group by visual similarity**\n- Wrong: Group Card, Panel, Container because they're all \"containers\"  \n- Right: Keep separate because they serve different architectural purposes\n\n**Don't group by shared infrastructure**\n- Wrong: Group AreaChart, BarChart, LineChart because they use shared cartesian components\n- Right: Keep separate because each chart works independently\n\n## Output Requirements\n- Return ONLY the JSON array\n- No additional commentary or explanation\n- Ensure valid JSON format\n- Include all required fields for each group\n- Validate that every component appears exactly once\n- Most groups should contain only one component";
+export declare const REPO_INDEXING_GROUP_PROMPT = "# Component Repository Analysis and Grouping\n\n## Objective\nAnalyze the repository to identify and categorize components based on **mandatory architectural interdependency**, creating groups ONLY when components literally cannot function independently and MUST be used together.\n\n## Component Grouping Philosophy - STRICT CRITERIA\n\n### ONLY Group Components That Meet ALL These Requirements:\n\n1. **Mandatory Compositional Architecture**\n   - Components that literally cannot render or function without their counterparts\n   - Parent components that are meaningless without specific child components\n   - Child components that will throw errors or fail without their required parent\n   - Example: `Table` requires `TableHeader`, `TableBody`, `TableRow`, `TableCell` to be functional\n\n2. **Exclusive Required Context Dependencies**\n   - Components that share context where the context is NOT optional\n   - Child components that will fail without the parent's required context\n   - Components with hard-coded provider-consumer relationships that cannot be bypassed\n   - Example: `FormField` + `FormLabel` + `FormControl` sharing required form context\n\n3. **Critical Runtime Dependencies**\n   - Components that reference each other's internal APIs or state directly\n   - Components that communicate through required internal protocols\n   - Components where removing one breaks the others at runtime\n\n### What MUST REMAIN SEPARATE - Even If They Share Code\n\n**Shared Infrastructure \u2260 Interdependency**\n- AreaChart, BarChart, LineChart are SEPARATE even if they use shared cartesian infrastructure\n- Each chart can render independently without the others\n- Shared internal components are implementation details, not architectural coupling\n\n**Thematic Similarity \u2260 Coupling**  \n- Button, IconButton, ToggleButton stay separate (each works alone)\n- Input, Select, TextArea stay separate (independent form controls)\n- Card, Panel, Modal stay separate (independent containers)\n\n**Optional Composition \u2260 Required Composition**\n- Components that CAN work together but don't HAVE to\n- Components where composition is for convenience, not necessity\n\n## Strict Validation Test\nBefore grouping ANY components, ask these questions. ALL must be \"YES\":\n\n1. **Removal Test**: If I remove one component from this group, do the others become non-functional or throw errors?\n2. **Independence Test**: Can ANY component in this group render successfully in complete isolation?\n3. **Context Test**: Do these components share context that is absolutely required (not optional)?\n4. **API Test**: Do these components directly call each other's methods or access each other's internal state?\n\nIf ANY answer is \"NO\" \u2192 DO NOT GROUP\n\n## Examples of CORRECT Grouping\n\n** Table Group** (Critical Coupling)\n```json\n{\n  \"name\": \"Table\",\n  \"components\": [\"Table\", \"TableHeader\", \"TableBody\", \"TableRow\", \"TableCell\"],\n}\n```\nWhy: Table component cannot render without TableHeader, TableBody, etc. Each piece is meaningless alone.\n\n**Form Field Group** (Strong Coupling)  \n```json\n{\n  \"name\": \"FormField\", \n  \"components\": [\"FormField\", \"FormLabel\", \"FormControl\", \"FormMessage\"]\n}\n```\nWhy: These share required form context and cannot function independently.\n\n## Examples of INCORRECT Grouping\n\n** Charts Group** (Shared Infrastructure \u2260 Coupling)\n```json\n// WRONG - Don't do this\n{\n  \"name\": \"Charts\",\n  \"components\": [\"AreaChart\", \"BarChart\", \"LineChart\", \"PieChart\"]\n}\n```\nWhy: Each chart renders independently. Shared infrastructure is an implementation detail.\n\n** Button Group** (Thematic Similarity \u2260 Coupling)\n```json\n// WRONG - Don't do this  \n{\n  \"name\": \"Buttons\",\n  \"components\": [\"Button\", \"IconButton\", \"ToggleButton\"]\n}\n```\nWhy: Each button type works completely independently.\n\n## Default Assumption: KEEP SEPARATE\n- When in doubt, create separate groups for each component\n- Err on the side of independence rather than grouping\n- Most components should end up in individual groups\n\n## Instructions\n\n### 1. Component Discovery\n{{component-discovery}}\n\n### 2. Interdependency Analysis\nFor each component, analyze:\n- **Required Dependencies**: What other components MUST be present for this to work?\n- **Context Requirements**: Does this component require specific context providers?\n- **Compositional Rules**: Are there mandatory parent-child relationships?\n- **Shared State**: Do components communicate through shared internal state?\n\n### 3. Coupling Strength Assessment\nEvaluate coupling strength:\n- **Critical Coupling**: Components cannot function without each other\n- **Strong Coupling**: Components are designed to work together with shared context\n- **Moderate Coupling**: Components enhance each other but can work independently\n- **Weak Coupling**: Components are thematically related but functionally independent\n\n### 4. Group Formation Rules\n- **Group together**: Components with Critical or Strong coupling\n- **Consider grouping**: Components with Moderate coupling (case-by-case basis)\n- **Keep separate**: Components with Weak coupling or functional independence\n\n### 5. Relevant Files Collection\nFor each group, include:\n- Primary component files (.tsx, .ts)\n- Context providers or shared state files\n- Type definition files specific to the group\n- Hook files that bind the components together\n- Test files that test the group as a unit\n- Documentation files specific to the group\n- Example files showing the components working together\n\n## Required Output Format\n\nGenerate a component-groups.json file with this structure:\n\n```json\n{{output-format}}\n```\n\n### Coupling Strength Definitions:\n- **\"critical\"**: Components cannot function without each other (Table group)\n- **\"strong\"**: Components share exclusive context/state (Form group)  \n- **\"moderate\"**: Components enhance each other but can work alone (ButtonGroup + Button)\n- **\"none\"**: Component is functionally independent (standalone Button)\n\n## Quality Requirements\n\n**Be Conservative:**\n- Prefer individual component groups over multi-component groups\n- Only group when there's undeniable architectural interdependency\n- Most components should be individual groups\n\n**Component Coverage:**\n{{component-coverage}}\n- Every component must appear in exactly one group\n- Prefer smaller, focused groups over large, loosely-coupled groups\n- Create individual groups for truly independent components\n\n**Grouping Validation:**\nFor each proposed group, ask:\n1. Would removing any component make the others useless or broken?\n2. Is there a required parent-child rendering relationship?\n3. Do they share mandatory (not optional) context or state?\n\nIf you can't answer \"YES\" confidently to at least one of these, keep components separate.\n\n**File Selection:**\n- Include files that are essential to understanding the group's architecture\n- Focus on files that show interdependencies between components\n- Include context providers, shared hooks, and type definitions\n- Exclude generic utility files unless they're group-specific\n\n## Anti-Patterns to Avoid\n\n**Don't group by theme alone**\n- Wrong: Group Button, IconButton, ToggleButton because they're all \"buttons\"\n- Right: Keep them separate because each works independently\n\n**Don't create mega-groups**  \n- Wrong: Group all form-related components together\n- Right: Group only those that share context (FormField + FormLabel + FormControl)\n\n**Don't group by visual similarity**\n- Wrong: Group Card, Panel, Container because they're all \"containers\"  \n- Right: Keep separate because they serve different architectural purposes\n\n**Don't group by shared infrastructure**\n- Wrong: Group AreaChart, BarChart, LineChart because they use shared cartesian components\n- Right: Keep separate because each chart works independently\n\n## Output Requirements\n- Return ONLY the JSON array\n- No additional commentary or explanation\n- Ensure valid JSON format\n- Include all required fields for each group\n- Validate that every component appears exactly once\n- Most groups should contain only one component";