builder.io 1.6.86 → 1.6.88

package/types/cli/abort-signal-any.d.ts

@@ -1 +1 @@
-export declare function abortSignalAny(signals: AbortSignal[]): AbortSignal;
+export declare function abortSignalAny(input: (AbortSignal | undefined)[]): AbortSignal;

package/types/cli/code-tools.d.ts

@@ -1,4 +1,4 @@
-import type { CodeGenTools, CommitMode, ContentMessageItemToolResult, ProjectFile, WorkspaceFolder } from "$/ai-utils";
+import type { CodeGenTools, CommitMode, ContentMessageItemToolResult, FusionConfig, ProjectFile, WorkspaceFolder } from "$/ai-utils";
 import type { DevToolsSys } from "../core";
 import { type DevServerOrchestrator } from "./launch/dev-server-orchestrator";
 import type { CodeGenEventEmitter } from "./codegen";
@@ -37,6 +37,7 @@ export interface ToolContext extends Partial<FusionContext> {
         path: string;
         name?: string;
     }>;
+    patchFusionConfig: (patch: Partial<FusionConfig>) => void;
     readFile: (filePath: string) => Promise<string | null>;
     writeFile: (filePath: string, content: string | Uint8Array) => Promise<boolean>;
     deleteFile: (filePath: string) => Promise<boolean>;

package/types/cli/codegen.d.ts

@@ -1,6 +1,6 @@
 import type { DevToolsSys } from "../types";
 import { type Credentials } from "./credentials";
-import type { CodegenFeedback, CodegenTurn, CommitMode, CustomInstruction, FusionConfig, GenerateCompletionState, GenerateCompletionStep, GenerateCompletionStepGit, GenerateUserMessage, UserContext, WorkspaceConfiguration, WorkspaceFolder } from "$/ai-utils";
+import type { CodegenFeedback, CodegenTurn, CommitMode, CustomInstruction, GenerateCompletionState, GenerateCompletionStep, GenerateCompletionStepGit, GenerateUserMessage, UserContext, WorkspaceConfiguration, WorkspaceFolder } from "$/ai-utils";
 import prettier from "prettier";
 import { type FusionContext } from "./code-tools";
 import EventEmitter from "node:events";
@@ -39,7 +39,6 @@ export type CodeGenSessionOptions = CodeGenSessionOptionsSession | CodeGenSessio
 export type CodeGenEventEmitter = EventEmitter<{
     step: [GenerateCompletionStep];
     idle: [];
-    fusionConfigPatch: [Partial<FusionConfig>];
 }>;
 export declare class CodeGenSession {
     #private;
@@ -159,8 +158,11 @@ export declare class CodeGenSession {
     sendMessage(message: GenerateUserMessage, immediate?: boolean): Promise<void>;
     getTurns(): CodegenTurn[];
     getSessionContext(): SessionContext;
+    runSetupCommand(): Promise<import("./launch/dev-server-orchestrator").SetupCommandResult | undefined>;
+    abortSetupCommand(): void;
     abort(cleanCurrentMessage?: boolean): Promise<boolean>;
     stopEventLoop(): Promise<void>;
+    requestRefresh(): void;
     close(): Promise<void>;
     emitGitStatus(): Promise<GenerateCompletionStepGit | null>;
     connectToEventLoop(shouldReplay: boolean, onStep: (step: GenerateCompletionStep) => void): () => void;

package/types/cli/launch/InitStateMachine.d.ts

@@ -18,6 +18,7 @@ export interface InitConfig {
     maxRetryDelayMs?: number;
     sys: DevToolsSys;
     debug?: boolean;
+    runSetupCommand: boolean;
 }
 export declare enum InitErrorType {
     FATAL = "fatal",

package/types/cli/launch/dev-server-orchestrator.d.ts

@@ -1,17 +1,33 @@
 import type { DevToolsSys } from "@builder.io/dev-tools/core";
 import { type RequestHandler as ProxyRequestHandler } from "http-proxy-middleware";
+import EventEmitter from "events";
 import { type ChildProcessByStdio } from "node:child_process";
 import type { Readable } from "node:stream";
 import type { FusionConfig } from "$/ai-utils";
-export type RunCommandState = "running" | "stopped" | "idle";
+export type DevCommandState = "running" | "stopped" | "unset";
+export type SetupCommandState = "not-installed" | "installing" | "installed" | "install-failed";
+export type DevServerState = Exclude<SetupCommandState | DevCommandState, "installed">;
+export interface SetupCommandResult {
+    code: number | null;
+    output: string;
+}
 export interface DevServerOrchestrator {
-    command: string;
-    state: RunCommandState;
+    devCommand: string;
+    setupCommand: string | undefined;
+    setupState: SetupCommandState;
+    devState: DevCommandState;
+    state: DevServerState;
     proxyTarget: string;
     proxyPort: number;
     proxyMiddleware: ProxyRequestHandler | undefined;
     pid: number | undefined;
-    ensureRunning: (abortSignal?: AbortSignal) => Promise<boolean>;
+    abortSetupCommand: () => void;
+    setEnvVariable: (key: string, value: string | undefined) => void;
+    ensureDevCommand: (abortSignal?: AbortSignal) => Promise<boolean>;
+    ensureSetupCommand: (abortSignal?: AbortSignal) => Promise<boolean>;
+    setupCommandPromise: Promise<SetupCommandResult> | undefined;
+    runSetupCommand: (signal?: AbortSignal) => Promise<SetupCommandResult>;
+    setSetupCommand: (newCommand: string, signal?: AbortSignal) => Promise<SetupCommandResult>;
     setCommand: (newCommand: string, signal?: AbortSignal) => Promise<boolean>;
     setPort: (newPort: number) => Promise<boolean>;
     pingServer: (signal?: AbortSignal) => Promise<Response>;
@@ -21,12 +37,20 @@ export interface DevServerOrchestrator {
     getAllStdout: () => string;
     getAllStderr: () => string;
     getOutput: () => string;
+    getSetupOutput: () => string;
     waitUntilIdle: (initialWaitMs?: number, idleTimeMs?: number) => Promise<void>;
     onClose: (callback: (code: number | null) => void) => void;
-    onStdout: (callback: (data: string) => void) => void;
-    onStderr: (callback: (data: string) => void) => void;
     restart: (abortSignal?: AbortSignal) => Promise<void>;
+    emitter: EventEmitter<{
+        close: [number | null];
+        stdout: [string];
+        stderr: [string];
+        installStdout: [string];
+        installStderr: [string];
+        setupState: [SetupCommandState];
+        devState: [DevCommandState];
+    }>;
 }
-export declare function devServerOrchestrator(sys: DevToolsSys, fusionConfig: FusionConfig): Promise<DevServerOrchestrator>;
+export declare function devServerOrchestrator(sys: DevToolsSys, fusionConfig: FusionConfig, initialSetupState: "installed" | "not-installed" | "install-failed"): Promise<DevServerOrchestrator>;
 export declare const checkPortsListenedByPid: (pid: number) => number[];
 export declare function killProcess(sys: DevToolsSys, proc: ChildProcessByStdio<null, Readable, Readable> | undefined, abortSignal?: AbortSignal, timeout?: number): Promise<boolean>;

package/types/cli/launch/github.d.ts

@@ -1,7 +1,7 @@
 import type { DevToolsSys } from "@builder.io/dev-tools/core";
 import type { Credentials } from "cli/credentials";
 export declare const getInitialDescription: (projectId: string) => string;
-export declare function updatePRDescription({ repoFullName, githubToken, prNumber, projectId, sys, credentials, builderProjectBranchName, }: {
+export declare function updatePRDescription({ repoFullName, githubToken, prNumber, projectId, sys, credentials, builderProjectBranchName, gitWorkingDirectory, }: {
     repoFullName: string;
     githubToken: string;
     prNumber: number;
@@ -9,6 +9,7 @@ export declare function updatePRDescription({ repoFullName, githubToken, prNumbe
     sys: DevToolsSys;
     credentials: Credentials;
     builderProjectBranchName: string | undefined;
+    gitWorkingDirectory?: string;
 }): Promise<{
     success: boolean;
     lastTurn: any;

package/types/cli/launch/logger.d.ts

@@ -1,5 +1,3 @@
-import type { ChildProcessByStdio } from "child_process";
-import type { Readable } from "stream";
 /**
  * Initialize logging by wrapping all console methods to write to logs file
  */
@@ -8,10 +6,6 @@ export declare function initializeLogging(): void;
  * Reset console methods to their original state
  */
 export declare function resetLogging(): void;
-/**
- * Capture and log child process output
- */
-export declare function setupChildProcessLogging(childProcess: ChildProcessByStdio<null, Readable, Readable>, prefix: string): void;
 /**
  * Display intro message with logging
  */

package/types/cli/utils/component-group-mdx-prompt.d.ts

@@ -1 +1 @@
-export declare const COMPONENT_GROUP_MDX_PROMPT = "# Component Group Documentation Generation\n\n## Objective\nGenerate comprehensive MDX documentation for a specific component group, analyzing their interfaces, relationships, and usage patterns using only the relevant files provided in the input.\n\n## Instructions\n\n### 1. Component Analysis\nFor the given component group, analyze each relevant file by:\n- **Interface examination** - Extract and document all props, their types, and descriptions\n- **Usage pattern analysis** - Identify how components work together\n- **Relationship mapping** - Document dependencies and coupling between components\n- **Example extraction** - Find real usage examples from the codebase\n\n### 2. Documentation Structure\nCreate comprehensive documentation covering:\n- **Group overview** - Purpose and architectural decisions\n- **Component interfaces** - Detailed prop documentation\n- **Usage examples** - Practical code examples\n- **Best practices** - Recommended usage patterns\n\n## Required Output Format\n\nGenerate an MDX file with this structure:\n\n```mdx\n---\n# {{GROUP_NAME}} Components\n\n## Overview\n[Detailed description of the component group, its purpose, and architectural decisions]\n\n## Components\n\n### [Component1Name]\n\n**Interface:**\n```typescript\ninterface [Component1]Props {\n  // Document all props with types and descriptions\n  property: string; // Description of what this prop does\n  onAction?: () => void; // Optional callback description\n}\n```\n\n**Usage Example:**\n```tsx\nimport { [Component1] } from '@cloudscape-design/components';\n\nfunction Example() {\n  return (\n    <[Component1]\n      property=\"value\"\n      onAction={() => console.log('action')}\n    >\n      Content\n    </[Component1]>\n  );\n}\n```\n\n### [Component2Name]\n[Repeat structure for each component]\n\n## Component Relationships\n\n[Explain how components in this group work together, including:]\n- Shared contexts or state\n- Compositional patterns\n- Data flow between components\n- Common usage combinations\n\n## Best Practices\n\n- [Practice 1: Specific recommendation]\n- [Practice 2: Another recommendation]\n- [Practice 3: Usage pattern guidance]\n\n## Common Patterns\n\n### Pattern 1: [Pattern Name]\n```tsx\n// Example of common usage pattern\n<[ParentComponent]>\n  <[ChildComponent1] />\n  <[ChildComponent2] />\n</[ParentComponent]>\n```\n\n### Pattern 2: [Another Pattern]\n```tsx\n// Another common pattern\n```\n\n## Related Groups\n\n- [Link to related component groups]\n- [Cross-references to components used together]\n```\n\n## File Generation Requirements\n\n**File Naming:**\n- Use kebab-case derived from group name: `{{GROUP_NAME_KEBAB}}.mdx`\n- Place in `repo-indexing/` folder\n- Example: `repo-indexing/{{GROUP_NAME_KEBAB}}.mdx`\n\n**Content Requirements:**\n1. **Extract real interfaces** - Don't create placeholder interfaces, extract actual TypeScript interfaces from the codebase\n2. **Include practical examples** - Use realistic, working code examples\n3. **Document all props** - Include type information, default values, and descriptions\n4. **Explain relationships** - Focus on how components work together within the group\n5. **Provide context** - Explain architectural decisions and design patterns\n\n**Quality Standards:**\n- All code examples must be syntactically correct\n- Interface documentation must match actual component props\n- Examples should demonstrate real-world usage scenarios\n- Include accessibility considerations where relevant\n\n## Input Format\nYou will receive a single component group object:\n```json\n{\n  \"name\": \"{{GROUP_NAME}}\", \n  \"description\": \"{{GROUP_DESCRIPTION}}\",\n  \"components\": [{{COMPONENT_LIST}}],\n  \"relevantFiles\": [{{FILE_LIST}}]\n}\n```\n\n## Output\nReturn only the complete MDX file content, ready to be saved as `repo-indexing/{{GROUP_NAME_KEBAB}}.mdx`";
+export declare const COMPONENT_GROUP_MDX_PROMPT = "# Component Group Documentation Generation\n\n## Objective\nGenerate comprehensive MDX documentation for a specific component group, analyzing their interfaces, relationships, and usage patterns using only the relevant files provided in the input.\n\n## Instructions\n\n### 1. Component Analysis\nFor the given component group, analyze each relevant file by:\n- **Interdependency mapping** - Document how components depend on each other\n- **Interface examination** - Extract and document all props, their types, and descriptions\n- **Context analysis** - Identify shared state, contexts, or communication patterns\n- **Compositional patterns** - Document required parent-child relationships\n- **Usage pattern analysis** - Identify how components work together\n- **Example extraction** - Find real usage examples from the codebase\n\n### 2. Documentation Structure\nCreate comprehensive documentation covering:\n- **Group rationale** - Why these components work together and when to use them\n- **Architectural overview** - How the components form a cohesive system\n- **Component interfaces** - Detailed prop documentation with interdependencies\n- **Composition patterns** - Required and optional usage combinations\n- **Integration examples** - Real-world scenarios showing the group in action\n- **Best practices** - Recommended usage patterns and guidelines\n\n## Required Output Format\n\nGenerate an MDX file with this structure:\n\n```mdx\n---\n# {{GROUP_NAME}} Components\n\n## Overview\n\n### Purpose\n{{GROUP_DESCRIPTION}}\n\n### When to Use\n[Expand on the use cases mentioned in the description - be specific about scenarios, user needs, and implementation contexts]\n\n### Architecture\n[Explain the architectural pattern based on coupling strength:]\n- **Critical/Strong Coupling**: Describe the required relationships, shared context, or compositional hierarchy\n- **Moderate Coupling**: Explain how components enhance each other\n- **No Coupling**: Note that this is a standalone component\n\n### Component Interdependencies\n[Map out component relationships - only for groups with coupling:]\n- Required parent-child relationships\n- Shared context dependencies  \n- Communication patterns between components\n\n## Components\n\n### [PrimaryComponent] {Primary Component for groups with coupling}\n[Mark the main/root component for coupled groups]\n\n**Purpose:** [What this specific component does within the group]\n\n**Interface:**\n```typescript\ninterface [PrimaryComponent]Props {\n  // Document all props with types and descriptions\n  children: React.ReactNode; // Required child components (for coupled groups)\n  property: string; // Description of what this prop does\n  onAction?: () => void; // Optional callback description\n}\n```\n\n**Dependencies:** [For coupled groups - what this component requires]\n**Provides:** [For coupled groups - what context/state this component provides to children]\n\n**Usage Example:**\n```tsx\nimport { [PrimaryComponent] } from '@your-library/components';\n\nfunction Example() {\n  return (\n    <[PrimaryComponent]\n      property=\"value\"\n      onAction={() => console.log('action')}\n    >\n      {/* Required children for coupled groups */}\n    </[PrimaryComponent]>\n  );\n}\n```\n\n### [DependentComponent] {Dependent Component for groups with coupling}\n[Mark components that depend on the primary component]\n\n**Purpose:** [What this specific component does within the group]\n\n**Interface:**\n```typescript\ninterface [DependentComponent]Props {\n  // Props specific to this component\n  // Note any props that are passed down from parent context\n}\n```\n\n**Context Dependencies:** [What context/state this component requires from parent]\n**Parent Requirements:** [Required parent components for proper functionality]\n\n**Usage Example:**\n```tsx\n// Must be used within [PrimaryComponent] for coupled groups\n<[PrimaryComponent]>\n  <[DependentComponent] prop=\"value\">\n    Content\n  </[DependentComponent]>\n</[PrimaryComponent]>\n```\n\n### [StandaloneComponent] {For uncoupled components}\n[For components with no coupling]\n\n**Purpose:** [What this component does and when to use it]\n\n**Interface:**\n```typescript\ninterface [StandaloneComponent]Props {\n  // All props with types and descriptions\n}\n```\n\n**Usage Example:**\n```tsx\nimport { [StandaloneComponent] } from '@your-library/components';\n\nfunction Example() {\n  return (\n    <[StandaloneComponent]\n      property=\"value\"\n      onAction={() => console.log('action')}\n    />\n  );\n}\n```\n\n## Integration Patterns\n\n### Basic Usage {Only for coupled groups}\n```tsx\nimport { [PrimaryComponent], [DependentComponent1], [DependentComponent2] } from '@your-library/components';\n\n// Minimal required structure\nfunction BasicExample() {\n  return (\n    <[PrimaryComponent]>\n      <[DependentComponent1]>Required content</[DependentComponent1]>\n      <[DependentComponent2]>More content</[DependentComponent2]>\n    </[PrimaryComponent]>\n  );\n}\n```\n\n### Advanced Usage {Only for coupled groups}\n```tsx\n// Complex usage with all features\nfunction AdvancedExample() {\n  return (\n    <[PrimaryComponent] \n      property=\"value\" \n      onAction={handleAction}\n    >\n      <[DependentComponent1] prop=\"value\">\n        <Content />\n      </[DependentComponent1]>\n      <[DependentComponent2] prop=\"value\">\n        <MoreContent />\n      </[DependentComponent2]>\n    </[PrimaryComponent]>\n  );\n}\n```\n\n### Common Variations {Adapt based on component types}\n```tsx\n// Show different ways to use the component(s)\n// Include conditional rendering, different prop combinations, etc.\n```\n\n## Component Relationships {Only for coupled groups}\n\n### Data Flow\n[Explain how data flows between components in the group]\n\n### Context Sharing\n[Document shared contexts, providers, or state management]\n\n### Event Handling\n[Describe how events bubble up or propagate between components]\n\n## Best Practices\n\n### Usage Guidelines\n- [Specific recommendation based on component purpose and use cases]\n- [Another recommendation focusing on accessibility or performance]\n- [Usage pattern guidance based on the group's architecture]\n\n### Accessibility {When relevant}\n- [ARIA relationships between components for coupled groups]\n- [Keyboard navigation patterns]\n- [Screen reader considerations]\n\n### Performance {When relevant}\n- [Optimization recommendations]\n- [State management best practices]\n- [Rendering performance considerations]\n\n## Common Patterns {Expand based on component functionality}\n\n### Pattern 1: [Specific Pattern Name]\n```tsx\n// Example showing a specific usage pattern\n// Include comments explaining why this pattern is recommended\n```\n\n### Pattern 2: [Another Pattern Name]\n```tsx\n// Another common pattern with explanation\n```\n\n```\n\n## File Generation Requirements\n\n**File Naming:**\n- Use kebab-case derived from group name: `{{GROUP_NAME_KEBAB}}.mdx`\n- Place in `repo-indexing/` folder\n- Example: `repo-indexing/{{GROUP_NAME_KEBAB}}.mdx`\n\n**Content Requirements:**\n1. **Use coupling strength context** - Adapt documentation structure based on couplingStrength value\n2. **Extract real interfaces** - Don't create placeholder interfaces, extract actual TypeScript interfaces from the codebase\n3. **Leverage group description** - Expand on the provided description with specific use cases and implementation guidance\n4. **Document interdependencies** - For coupled groups, clearly explain component relationships and requirements\n5. **Include practical examples** - Use realistic, working code examples that demonstrate proper usage\n6. **Show integration patterns** - For coupled groups, demonstrate required composition patterns\n**Coupling-Specific Requirements:**\n- **Critical/Strong Coupling**: Focus on required relationships, composition patterns, and shared context\n- **Moderate Coupling**: Show how components enhance each other and optional usage patterns  \n- **No Coupling**: Document standalone usage, variants, and individual component capabilities\n\n\n## Input Format\nYou will receive a single component group object:\n```json\n{\n  \"name\": \"{{GROUP_NAME}}\", \n  \"description\": \"{{GROUP_DESCRIPTION}}\",\n  \"components\": [{{COMPONENT_LIST}}],\n  \"relevantFiles\": [{{FILE_LIST}}],\n}\n```\n\n## Output\nReturn only the complete MDX file content, ready to be saved as `repo-indexing/{{GROUP_NAME_KEBAB}}.mdx`";

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 all components, focusing on component coupling and logical groupings.\n\n## Instructions\n\n### 1. Component Discovery\n- Scan the entire repository for all components\n\n### 2. Coupling Analysis\nIdentify components that are deeply coupled through:\n- **Naming patterns** (e.g., Card, CardHeader, CardContent, CardFooter)\n- **Functional relationships** (components designed to work together)\n- **Compositional patterns** (parent-child component relationships)\n\n### 3. Grouping Criteria\nGroup components based on:\n- **Semantic relationship** (related functionality)\n- **Usage patterns** (components typically used together)\n\n### 4. Relevant Files\n- In the relevantFiles array, include all important files like the component, any example files, and any other files that are important to the component.\n\n## Required Output Format\n\nGenerate a component-groups.json file with this shape: \n[\n  {\n    \"name\": \"Button\", \n    \"description\": \"Strongest coupling through shared props and functionality\",\n    \"components\": [\"Button\", \"ButtonDropdown\", \"ButtonGroup\", \"ToggleButton\"],\n    \"relevantFiles\": [\"button.tsx\", \"button-dropdown.tsx\", \"button-group.tsx\", \"toggle-button.tsx\"]\n  },\n  {\n    \"name\": \"Form\",\n    \"description\": \"Deeply coupled through FormFieldContext and shared validation patterns\",\n    \"components\": [\"Form\", \"FormField\", \"Input\", \"Textarea\", \"Checkbox\"],\n    \"relevantFiles\": [\"form.tsx\", \"form-field.tsx\", \"input.tsx\", \"textarea.tsx\", \"checkbox.tsx\"]\n  }\n]\n\n**Component Coverage:**\n- Include ALL components found in the repository\n- Every component must appear in exactly one group\n- Create standalone groups for ungrouped components with couplingStrength: \"none\"\n- Only return the JSON array, nothing else";
+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";

package/types/cli/utils/workspace-path-resolver.d.ts

@@ -0,0 +1,52 @@
+import type { WorkspaceFolder, WorkspaceConfiguration } from "@builder.io/ai-utils";
+import type { DevToolsSys } from "../../types";
+export interface ResolveWorkspacePathOptions {
+    filePath: string;
+    forceWorkspace?: boolean;
+    workspace?: WorkspaceConfiguration;
+    workingDirectory: string;
+    sys: DevToolsSys;
+    canCollapseWorkspace?: boolean;
+}
+export interface ResolveWorkspacePathResult {
+    resolvedPath: string;
+    workspaceFolder?: WorkspaceFolder;
+}
+/**
+ * Resolves a workspace file path to its actual file system path.
+ *
+ * This function handles various workspace configurations:
+ * - Single workspace named "." (treats paths as direct relative paths)
+ * - Multiple workspaces (matches path prefixes to workspace names/folder names)
+ * - No workspace configuration (falls back to working directory)
+ *
+ * @param options Configuration object containing all required parameters
+ * @param options.filePath A file path that may include a workspace prefix (e.g., "workspace1/path/to/file.js")
+ * @param options.forceWorkspace If true, will try the first workspace as fallback when no workspace folder is found
+ * @param options.workspace Optional workspace configuration with folders
+ * @param options.workingDirectory The base working directory to resolve paths against
+ * @param options.sys DevToolsSys object providing path resolution functions
+ * @returns Object containing the resolved file system path and matched workspace folder
+ *
+ * @example
+ * ```typescript
+ * import { createNodeSys } from '@builder.io/dev-tools/node';
+ *
+ * const result = resolveWorkspacePath({
+ *   filePath: 'frontend/src/components/Button.tsx',
+ *   workingDirectory: '/home/user/project',
+ *   sys: createNodeSys(),
+ *   workspace: {
+ *     folders: [
+ *       { name: 'frontend', path: './packages/frontend' },
+ *       { name: 'backend', path: './packages/backend' }
+ *     ]
+ *   }
+ * });
+ * // Returns: {
+ * //   resolvedPath: '/home/user/project/packages/frontend/src/components/Button.tsx',
+ * //   workspaceFolder: { name: 'frontend', path: './packages/frontend' }
+ * // }
+ * ```
+ */
+export declare function resolveWorkspacePath(options: ResolveWorkspacePathOptions): ResolveWorkspacePathResult;

package/types/cli/utils/workspace-path-resolver.unit.d.ts

@@ -0,0 +1 @@
+export {};

package/types/common/builder/builder-sdks.d.ts

@@ -5,5 +5,6 @@ export declare const SUPPORTED_FRAMEWORKS: {
     angular: string;
     next: string;
     qwik: string;
+    vue: string;
 };
 export declare function getSDKDetailsForFramework(framework: string): SDKVersionInfo[];

package/types/common/utils.d.ts

@@ -20,3 +20,9 @@ export declare function shouldSkipFolder(sys: DevToolsSys, skipFolders: Set<stri
 export declare function getPackageManager(): string;
 export declare function isWindows(): boolean;
 export declare function builderNpxPackage(): "\"@builder.io/dev-tools\"" | "builder.io";
+/**
+ * Sanitizes a component name for use in filesystem paths by replacing invalid characters with underscores
+ * @param name The component name to sanitize
+ * @returns A sanitized string safe for use in filesystem paths
+ */
+export declare function sanitizeComponentName(name: string): string;

package/types/core/adapters/vue/index.d.ts

@@ -0,0 +1,14 @@
+import type { CreateDevToolsOptions, DevToolsAdapter, DevToolsSys } from "../../../types";
+export declare function createVueDevTools(sys: CreateDevToolsOptions): Promise<DevToolsAdapter>;
+export declare function createVueDevToolsSys(sys: DevToolsSys): Promise<VueDevToolsSys>;
+export interface VueDevToolsSys extends DevToolsSys {
+    srcDir: string | null;
+    componentsDir: string;
+    builderComponentPath: string;
+    registryPath: string;
+    vueConfigPath: string;
+    typescriptEnabled: boolean;
+    configType: "webpack" | "vite" | "";
+    isNuxt: boolean;
+    addExternalPackage: (pkgName: string) => void;
+}

package/types/core/adapters/vue/vue-api-key.d.ts

@@ -0,0 +1,6 @@
+import type { VueDevToolsSys } from "./index";
+import type { EnvInfo } from "../../../types";
+export declare function getVueApiKey(sys: VueDevToolsSys): Promise<EnvInfo>;
+export declare function setVueApiKey(sys: VueDevToolsSys, publicApiKey: string): Promise<EnvInfo>;
+export declare const VUE_VITE_BUILDER_KEY_ENV = "VITE_PUBLIC_BUILDER_KEY";
+export declare const VUE_WEBPACK_BUILDER_KEY_ENV = "PUBLIC_BUILDER_KEY";

package/types/core/adapters/vue/vue-components.d.ts

@@ -0,0 +1,4 @@
+import type { VueDevToolsSys } from "./index";
+import type { ComponentInfo } from "../../../types";
+export declare function parseVueComponent(sys: VueDevToolsSys, filePath: string, readAllInputTypes: boolean): Promise<ComponentInfo | null>;
+export declare function getVueComponentsFromPath(sys: VueDevToolsSys, filePath: string, readAllInputTypes: boolean): Promise<ComponentInfo[] | null>;

package/types/core/adapters/vue/vue-ensure-builder-setup.d.ts

@@ -0,0 +1,7 @@
+import type { VueDevToolsSys } from "./index";
+import type { ModifiedFile } from "../../../types";
+export declare function vueEnsureBuilderSetup(sys: VueDevToolsSys): Promise<{
+    errors: string[];
+}>;
+export declare function vueEnsureFigmaImportSetup(sys: VueDevToolsSys): Promise<ModifiedFile[]>;
+export declare function vueEnsureBuilderRegistry(sys: VueDevToolsSys): Promise<ModifiedFile[]>;

package/types/core/adapters/vue/vue-registry-parse.d.ts

@@ -0,0 +1,16 @@
+import type ts from "typescript";
+import type { ComponentInfo } from "../../../types";
+import type { VueDevToolsSys } from "./index";
+export declare function parseVueRegistryFromFile(sys: VueDevToolsSys): Promise<{
+    sourceFile: ts.SourceFile;
+    components: ComponentInfo[];
+}>;
+export declare function parseVueRegistryFromCode(sys: VueDevToolsSys, code: string): Promise<{
+    sourceFile: ts.SourceFile;
+    components: ComponentInfo[];
+}>;
+export declare function parseRegistryFromSource(sys: VueDevToolsSys, sourceFile: ts.SourceFile): Promise<{
+    sourceFile: ts.SourceFile;
+    components: ComponentInfo[];
+}>;
+export declare function parseVueRegisteredComponent(sys: VueDevToolsSys, sourceFile: ts.SourceFile, cmpObjLit: ts.Node): Promise<ComponentInfo | null>;

package/types/core/adapters/vue/vue-registry.d.ts

@@ -0,0 +1,5 @@
+import type { ComponentRegistry } from "../../../types";
+import type { VueDevToolsSys } from "./index";
+export declare function vueComponentRegistry(sys: VueDevToolsSys, options: {
+    readAllInputTypes: boolean;
+}): Promise<ComponentRegistry>;