You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
-[Test-Driven Development (TDD) Approach](#test-driven-development-tdd-approach)
32
33
-[TDD Cycle](#tdd-cycle)
33
34
-[Running Tests](#running-tests)
34
-
-[Running All Tests](#running-all-tests)
35
-
-[Running Specific Test Files](#running-specific-test-files)
36
-
-[Running Tests by Pattern](#running-tests-by-pattern)
37
35
-[TDD Workflow for New Features](#tdd-workflow-for-new-features)
38
36
-[Test Organization](#test-organization)
39
37
-[Best Practices](#best-practices)
@@ -47,25 +45,27 @@ The primary goal of this codebase is to automate the creation of TypeBox schemas
47
45
48
46
## Core Component
49
47
50
-
The main logic for code generation resides in the <mcfilename="ts-morph-codegen.ts"path="src/ts-morph-codegen.ts"></mcfile> file. Its primary function, `generateCode`, takes a `SourceFile` object (representing a TypeScript file) as input and returns a string containing the generated TypeBox code.
48
+
The main logic for code generation resides in the <mcfilename="ts-morph-codegen.ts"path="src/ts-morph-codegen.ts"></mcfile> file. Its primary function, `generateCode`, takes a `GenerateCodeOptions` object as input and returns a string containing the generated TypeBox code. The input can be either a file path or source code string, with support for relative imports when using existing project contexts.
51
49
52
50
### Function Flow
53
51
54
-
1.**Initialization**: A new in-memory `SourceFile` (`temp.ts`) is created to build the generated code. Essential imports for TypeBox (`Type`, `Static`) are added.
52
+
1.**Input Processing**: The <mcfilename="input-handler.ts"path="src/input-handler.ts"></mcfile> module processes the input options to create a `SourceFile` object. This supports both file paths and source code strings, with proper validation for relative imports and path resolution.
53
+
54
+
2.**Initialization**: A new in-memory `SourceFile` (`output.ts`) is created to build the generated code. Essential imports for TypeBox (`Type`, `Static`) are added as separate import declarations for better compatibility.
55
55
56
-
2.**Parser Instantiation**: Instances of `ImportParser`, `EnumParser`, `TypeAliasParser`, and `FunctionDeclarationParser` are created, each responsible for handling specific types of declarations.
56
+
3.**Parser Instantiation**: Instances of `ImportParser`, `EnumParser`, `TypeAliasParser`, and `FunctionDeclarationParser` are created, each responsible for handling specific types of declarations.
57
57
58
-
3.**Import Processing**: The `ImportParser` is instantiated and processes all import declarations in the input `sourceFile` to resolve imported types from external files. This includes locating corresponding source files for relative module specifiers and processing type aliases from imported files.
58
+
4.**Import Processing**: The `ImportParser` is instantiated and processes all import declarations in the input `sourceFile` to resolve imported types from external files. This includes locating corresponding source files for relative module specifiers and processing type aliases from imported files.
59
59
60
-
4.**Enum Processing**: The `EnumParser` is instantiated and iterates through all `enum` declarations in the input `sourceFile`. For each enum, its original declaration is copied, a TypeBox `Type.Enum` schema is generated, and a corresponding static type alias is added.
60
+
5.**Enum Processing**: The `EnumParser` is instantiated and iterates through all `enum` declarations in the input `sourceFile`. For each enum, its original declaration is copied, a TypeBox `Type.Enum` schema is generated, and a corresponding static type alias is added.
61
61
62
-
5.**Type Alias Processing**: The `TypeAliasParser` is instantiated and iterates through all `type alias` declarations in the input `sourceFile`. For each type alias, its underlying type node is converted into a TypeBox-compatible type representation, a TypeBox schema is generated, and a corresponding static type alias is added.
62
+
6.**Type Alias Processing**: The `TypeAliasParser` is instantiated and iterates through all `type alias` declarations in the input `sourceFile`. For each type alias, its underlying type node is converted into a TypeBox-compatible type representation, a TypeBox schema is generated, and a corresponding static type alias is added.
63
63
64
-
6.**Interface Processing**: The `InterfaceParser` is instantiated and iterates through all `interface` declarations in the input `sourceFile`. For each interface, its properties and methods are converted into TypeBox object schemas with corresponding static type aliases.
64
+
7.**Interface Processing**: The `InterfaceParser` is instantiated and iterates through all `interface` declarations in the input `sourceFile`. For each interface, its properties and methods are converted into TypeBox object schemas with corresponding static type aliases.
65
65
66
-
7.**Function Declaration Processing**: The `FunctionDeclarationParser` is instantiated and iterates through all function declarations in the input `sourceFile`. For each function, its parameters, optional parameters, and return type are converted into TypeBox function schemas with corresponding static type aliases.
66
+
8.**Function Declaration Processing**: The `FunctionDeclarationParser` is instantiated and iterates through all function declarations in the input `sourceFile`. For each function, its parameters, optional parameters, and return type are converted into TypeBox function schemas with corresponding static type aliases.
67
67
68
-
8.**Output**: Finally, the full text content of the newly generated `temp.ts` source file (which now contains all the TypeBox schemas and static types) is returned as a string.
68
+
9.**Output**: Finally, the full text content of the newly generated `output.ts` source file (which now contains all the TypeBox schemas and static types) is returned as a string.
69
69
70
70
### Import Resolution and Dependency Management
71
71
@@ -103,25 +103,61 @@ The import resolution process works in two phases:
103
103
104
104
This approach ensures that complex import scenarios work correctly and generated code compiles without dependency errors.
105
105
106
-
## TSConfig Support
106
+
## Input Handling System
107
+
108
+
The <mcfilename="input-handler.ts"path="src/input-handler.ts"></mcfile> module provides flexible input processing capabilities for the code generation system. It supports multiple input methods and handles various edge cases related to file resolution and import validation.
109
+
110
+
### InputOptions Interface
111
+
112
+
The `InputOptions` interface defines the available input parameters:
113
+
114
+
```typescript
115
+
exportinterfaceInputOptions {
116
+
filePath?:string// Path to TypeScript file
117
+
sourceCode?:string// TypeScript source code as string
118
+
callerFile?:string// Context file path for relative import resolution
5.**Error Handling**: Provides clear error messages for invalid inputs and unresolvable paths
109
130
110
-
The TypeBox code generation system includes automatic support for TypeScript configuration files (tsconfig.json). The system automatically detects and parses the closest tsconfig.json file using `tsconfck.parseNative`, ensuring that generated code respects project-specific TypeScript compiler options, particularly the `verbatimModuleSyntax` setting, which affects how import statements are generated.
131
+
### Usage Patterns
111
132
112
-
### Usage Examples
133
+
-**File Path Input**: Automatically resolves and loads TypeScript files from disk
134
+
-**Source Code Input**: Processes TypeScript code directly from strings with validation
135
+
-**Project Context**: Enables proper relative import resolution when working with in-memory source files
113
136
114
-
####Basic Usage
137
+
## Basic Usage
115
138
116
139
```typescript
117
-
const result =generateCode(sourceFile)
140
+
const result =awaitgenerateCode({
141
+
sourceCode: sourceFile.getFullText(),
142
+
callerFile: sourceFile.getFilePath(),
143
+
})
118
144
```
119
145
120
-
####With Export Everything
146
+
### With Export Everything
121
147
122
148
```typescript
123
-
const result =generateCode(sourceFile, {
149
+
const result =awaitgenerateCode({
150
+
sourceCode: sourceFile.getFullText(),
124
151
exportEverything: true,
152
+
callerFile: sourceFile.getFilePath(),
153
+
})
154
+
```
155
+
156
+
### Using File Path
157
+
158
+
```typescript
159
+
const result =awaitgenerateCode({
160
+
filePath: './types.ts',
125
161
})
126
162
```
127
163
@@ -237,31 +273,7 @@ The optimizations maintain full backward compatibility and test reliability whil
237
273
238
274
### Performance Testing
239
275
240
-
To ensure the dependency collection system performs efficiently under various scenarios, comprehensive performance tests have been implemented in <mcfilename="dependency-collector.performance.test.ts"path="tests/ts-morph/dependency-collector.performance.test.ts"></mcfile>. These tests specifically target potential bottlenecks in dependency collection and import processing:
241
-
242
-
#### Test Categories
243
-
244
-
1.**Large Dependency Chains**:
245
-
-**Deep Import Chains**: Tests performance with 50+ levels of nested imports to verify the system handles deep dependency trees efficiently
246
-
-**Wide Import Trees**: Tests scenarios with 100+ parallel imports to ensure the system scales well with broad dependency graphs
247
-
248
-
2.**Cache Efficiency**:
249
-
-**Complex Type Structures**: Validates caching performance with intricate type definitions involving unions, intersections, and nested objects
250
-
-**Large Cache Operations**: Tests the system's ability to handle substantial cache sizes without performance degradation
251
-
252
-
3.**Repeated File Processing**:
253
-
-**Diamond Dependency Patterns**: Tests scenarios where multiple import paths converge on the same files, ensuring efficient deduplication
254
-
-**Complex Topological Sort**: Validates performance of dependency ordering algorithms with interconnected type relationships
255
-
256
-
4.**Memory Usage Patterns**:
257
-
-**Large Type Definitions**: Tests processing of substantial type definitions to ensure memory efficiency
258
-
-**Dependency Map Operations**: Validates performance of core dependency tracking data structures
259
-
260
-
These performance tests provide baseline measurements and help identify potential bottlenecks before they impact production usage. The tests are designed to complete within reasonable timeframes while exercising the system under stress conditions that could reveal performance issues not apparent in standard unit tests.
261
-
262
-
-**`ts-morph`**: The `ts-morph` library is heavily utilized for parsing, traversing, and manipulating the TypeScript Abstract Syntax Tree (AST). It provides a programmatic way to interact with TypeScript code.
263
-
264
-
-**`@sinclair/typebox`**: This is the target library for schema generation. It provides a powerful and performant way to define JSON schemas with TypeScript type inference.
276
+
To ensure the dependency collection system performs efficiently under various scenarios, comprehensive performance tests have been implemented in <mcfilename="dependency-collector.performance.test.ts"path="tests/ts-morph/dependency-collector.performance.test.ts"></mcfile>. These tests specifically target potential bottlenecks in dependency collection and import processing.
265
277
266
278
## Process Overview
267
279
@@ -286,33 +298,15 @@ This project follows a Test-Driven Development methodology to ensure code qualit
286
298
287
299
The project uses Bun as the test runner. Here are the key commands for running tests:
0 commit comments