-
Notifications
You must be signed in to change notification settings - Fork 3
Feat(backend)file generate function specific place #71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feat(backend)file generate function specific place #71
Conversation
<!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Release Notes - **New Features** - Introduced a new template for React applications using TypeScript and Vite, including essential setup files. - Added a main HTML entry point for the application. - Configured ESLint for improved code quality and best practices in TypeScript and React environments. - **Documentation** - Added a README file outlining setup instructions and recommended configurations for the template. - **Configuration** - New TypeScript and Vite configuration files created to optimize the development environment. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
Warning There were issues while running some tools. Please review the errors and either fix the tool’s configuration or disable the tool if it’s a critical failure. 🔧 eslint
backend/src/build-system/handlers/file-manager/file-generate/index.tsOops! Something went wrong! :( ESLint: 8.57.1 ESLint couldn't find the plugin "eslint-plugin-prettier". (The package "eslint-plugin-prettier" was not found when loaded as a Node module from the directory "/backend".) It's likely that the plugin isn't installed correctly. Try reinstalling by running the following:
The plugin "eslint-plugin-prettier" was referenced from the config file in "backend/.eslintrc.js". If you still can't figure out the problem, please stop by https://eslint.org/chat/help to chat with the team. WalkthroughThis pull request introduces comprehensive changes to the build system's utility functions and testing infrastructure. The modifications focus on enhancing path management, file generation, and context handling. Key updates include adding a new test suite for path utilities, introducing a project UUID in the build context, updating file utility functions, and refactoring import statements across multiple files. The changes aim to improve code organization, error handling, and project-specific tracking in the build system. Changes
Suggested labels
Suggested reviewers
Poem
Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 6
🔭 Outside diff range comments (2)
backend/src/build-system/handlers/file-manager/file-generate/index.ts (2)
Line range hint
19-21
: Fix empty projectSrcPath initializationInitializing projectSrcPath as an empty string could lead to issues with file generation. Consider retrieving the path from the context or configuration.
- // change here - const projectSrcPath = ''; + const projectSrcPath = context.getData('projectSrcPath') || path.join(process.cwd(), 'src'); this.generateFiles(JSON.stringify(fileArch, null, 2), projectSrcPath);
Line range hint
142-147
: Enhance error handling in resolveDependencyThe dependency resolution could be more robust with additional error handling and validation.
private resolveDependency(currentFile: string, dependency: string): string { + if (!currentFile || !dependency) { + throw new Error('Invalid arguments: currentFile and dependency must be provided'); + } + const currentDir = path.dirname(currentFile); // Check if the dependency is a file with an extension const hasExtension = path.extname(dependency).length > 0; + // Validate dependency path + if (dependency.includes('..')) { + throw new Error('Security: Traversal outside project directory is not allowed'); + } + // If the dependency doesn't have an extension and is not CSS/JS, assume it's a TypeScript file
🧹 Nitpick comments (8)
backend/src/build-system/utils/strings.ts (2)
12-14
: Strengthen the regex patternThe current regex pattern could be more robust:
- It's not anchored to word boundaries
- It might match nested tags incorrectly
- const jsonMatch = /<GENERATEDCODE>([\s\S]*?)<\/GENERATEDCODE>/m.exec( + const jsonMatch = /\b<GENERATEDCODE>\s*([\s\S]*?)\s*<\/GENERATEDCODE>\b/m.exec( markdownContent, );
22-25
: Enhance error loggingThe error message could include more context about the JSON content that failed to parse.
} catch (error) { - logger.error('Invalid JSON format in the Markdown content: ' + error); + logger.error( + 'Invalid JSON format in the Markdown content:\n' + + `Content: ${jsonMatch[1].substring(0, 100)}...\n` + + `Error: ${error}` + ); return null; }backend/src/build-system/utils/files.ts (1)
18-26
: Enhance error handling and loggingThe error handling could be more specific and informative.
try { // fs-extra's outputFile creates all directories if they don't exist await fs.outputFile(filePath, content, 'utf8'); return filePath; } catch (error) { - logger.error('Error saving generated code:', error); + const errorMessage = error instanceof Error ? error.message : String(error); + logger.error( + `Failed to save generated code to ${filePath}:\n` + + `Error: ${errorMessage}` + ); throw error; }backend/src/build-system/__tests__/test-file-create-and-path.spec.ts (1)
56-62
: Improve test assertionsThe test could be more comprehensive in its assertions.
it('should create and return the root directory', async () => { const rootDir = pathUtil.getRootDir(); await generateAndSaveCode(); expect(rootDir).toBe(ROOT_DIR); expect(existsSync(ROOT_DIR)).toBe(true); + expect(existsSync(path.join(ROOT_DIR, 'generated'))).toBe(true); + expect(existsSync(path.join(ROOT_DIR, 'generated', 'example.controller.ts'))).toBe(true); });backend/src/build-system/handlers/file-manager/file-arch/index.ts (2)
4-4
: Consider implementing the TODO for page-by-page analysisThe TODO comment indicates a planned feature for page-by-page analysis. This could enhance the architecture document generation process.
Would you like me to help create a detailed implementation plan or open a GitHub issue to track this enhancement?
Line range hint
83-107
: Consider enhancing file path validationThe current validation is good but could be strengthened by:
- Adding validation for maximum path length
- Checking for reserved filenames on different platforms
- Validating against common security patterns
private validateJsonData(jsonData: { files: Record<string, { dependsOn: string[] }>; }): boolean { const validPathRegex = /^[a-zA-Z0-9_\-/.]+$/; + const MAX_PATH_LENGTH = 255; + const RESERVED_NAMES = new Set(['CON', 'PRN', 'AUX', 'NUL', 'COM1']); + for (const [file, details] of Object.entries(jsonData.files)) { + // Check path length + if (file.length > MAX_PATH_LENGTH) { + this.logger.error(`File path exceeds maximum length: ${file}`); + return false; + } + + // Check for reserved names + const baseName = file.split('/').pop()?.split('.')[0].toUpperCase(); + if (baseName && RESERVED_NAMES.has(baseName)) { + this.logger.error(`File name uses reserved name: ${file}`); + return false; + } + // Validate the file path if (!validPathRegex.test(file)) {backend/src/build-system/context.ts (1)
14-18
: Consider adding UUID format validationThe GlobalDataKeys type now includes projectUUID, but there's no validation to ensure the UUID format is correct when retrieved.
export type GlobalDataKeys = | 'projectName' | 'description' | 'platform' | 'projectUUID'; + +// Add UUID validation helper +const isValidUUID = (uuid: string): boolean => { + const uuidRegex = /^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i; + return uuidRegex.test(uuid); +};backend/src/build-system/handlers/file-manager/file-generate/index.ts (1)
Line range hint
165-181
: Add retry mechanism for file creationThe file creation process could benefit from a retry mechanism to handle temporary filesystem issues.
private async createFile(filePath: string): Promise<void> { const dir = path.dirname(filePath); + const maxRetries = 3; + let retryCount = 0; + + while (retryCount < maxRetries) { + try { // Ensure the directory exists await fs.mkdir(dir, { recursive: true }); // Create the file with a placeholder content const content = `// Generated file: ${path.basename(filePath)}`; await fs.writeFile(filePath, content, 'utf8'); this.logger.log(`File created: ${filePath}`); + return; + } catch (error) { + retryCount++; + if (retryCount === maxRetries) throw error; + await new Promise(resolve => setTimeout(resolve, 1000 * retryCount)); + } + } }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
backend/src/build-system/__tests__/test-file-create-and-path.spec.ts
(1 hunks)backend/src/build-system/context.ts
(2 hunks)backend/src/build-system/handlers/file-manager/file-arch/index.ts
(1 hunks)backend/src/build-system/handlers/file-manager/file-generate/index.ts
(1 hunks)backend/src/build-system/utils/files.ts
(1 hunks)backend/src/build-system/utils/strings.ts
(1 hunks)backend/src/build-system/utils/util.ts
(0 hunks)backend/src/config/common-path.ts
(1 hunks)
💤 Files with no reviewable changes (1)
- backend/src/build-system/utils/util.ts
✅ Files skipped from review due to trivial changes (1)
- backend/src/config/common-path.ts
🔇 Additional comments (2)
backend/src/build-system/handlers/file-manager/file-arch/index.ts (1)
5-5
: Verify the behavior of moved FileUtil import
The FileUtil import has been moved from 'util' to 'strings'. Ensure that the extractJsonFromMarkdown
function maintains the same behavior in its new location.
✅ Verification successful
The results show that the extractJsonFromMarkdown
function maintains identical core functionality in both locations:
- Same function signature and return type
- Same regex pattern to extract JSON between
<GENERATEDCODE>
tags - Same error handling and return behavior
The only minor difference is the error logging: old version uses FileUtil.logger
while new version uses logger
directly, which is a common refactoring pattern when moving functions out of classes.
Import change is safe to use
The FileUtil.extractJsonFromMarkdown
function has been successfully moved to the strings utility file with identical core behavior maintained. The minor logger reference change doesn't impact the function's output.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Compare the implementation of extractJsonFromMarkdown between old and new locations
# Note: Using git show to view the old implementation
# Get the old implementation
git show HEAD^:backend/src/build-system/utils/util.ts | rg -A 10 'extractJsonFromMarkdown'
# Get the new implementation
rg -A 10 'extractJsonFromMarkdown' backend/src/build-system/utils/strings.ts
Length of output: 851
backend/src/build-system/context.ts (1)
46-48
: Verify UUID persistence across builds
The UUID is initialized in the constructor, but we should verify that it persists across different build stages and remains consistent throughout the project lifecycle.
✅ Verification successful
UUID is correctly managed within build context lifecycle
The projectUUID is stored in memory within the BuilderContext instance's private data object and is appropriately scoped to the build lifecycle. The implementation shows that:
- The UUID is initialized in the constructor and stored via
setData
- It's accessible throughout the build process via
getData
- The context is maintained for the duration of the build sequence
- The UUID is not required to persist across different build instances as each build context creates its own unique identifier
This is the correct implementation pattern for a build-scoped identifier.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for UUID persistence implementation
# Look for storage or caching of the UUID
# Search for UUID usage
rg -l "projectUUID" --type ts
# Check for persistence mechanisms
rg -l "persist.*UUID|save.*UUID|store.*UUID" --type ts
Length of output: 122
Script:
#!/bin/bash
# Let's analyze the context usage and persistence mechanisms more thoroughly
# Check the implementation of setData and how projectUUID is used
ast-grep --pattern 'setData($_,$_)'
# Look for any getData calls that might retrieve projectUUID
ast-grep --pattern 'getData($_)'
# Check the full context class implementation
rg -A 5 -B 5 "class.*Context" --type ts
# Look for any serialization or state management of Context
rg -A 3 "serialize|deserialize|save|load|state" --type ts
Length of output: 52282
Script:
#!/bin/bash
# Let's analyze the BuilderContext class implementation more thoroughly
# Check the full implementation of BuilderContext class
ast-grep --pattern 'class BuilderContext {
$$$
}'
# Look for getData implementation to understand how projectUUID is retrieved
ast-grep --pattern 'getData($_) {
$$$
}'
# Check for any persistence mechanisms in the build system
rg -A 5 "class.*BuilderContext|setData|getData" backend/src/build-system/context.ts
Length of output: 8421
if (!jsonMatch) { | ||
logger.error('No JSON found in the provided Markdown content.'); | ||
return null; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Add input validation
The function should validate the input parameter before processing.
+ if (!markdownContent || typeof markdownContent !== 'string') {
+ logger.error('Invalid input: markdownContent must be a non-empty string');
+ return null;
+ }
if (!jsonMatch) {
logger.error('No JSON found in the provided Markdown content.');
return null;
}
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
if (!jsonMatch) { | |
logger.error('No JSON found in the provided Markdown content.'); | |
return null; | |
} | |
if (!markdownContent || typeof markdownContent !== 'string') { | |
logger.error('Invalid input: markdownContent must be a non-empty string'); | |
return null; | |
} | |
if (!jsonMatch) { | |
logger.error('No JSON found in the provided Markdown content.'); | |
return null; | |
} |
export function extractJsonFromMarkdown(markdownContent: string): { | ||
files: Record<string, { dependsOn: string[] }>; | ||
} { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix return type to match implementation
The return type should include null
since the function can return null in error cases.
-export function extractJsonFromMarkdown(markdownContent: string): {
- files: Record<string, { dependsOn: string[] }>;
+export function extractJsonFromMarkdown(markdownContent: string): {
+ files: Record<string, { dependsOn: string[] }>;
+} | null {
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
export function extractJsonFromMarkdown(markdownContent: string): { | |
files: Record<string, { dependsOn: string[] }>; | |
} { | |
export function extractJsonFromMarkdown(markdownContent: string): { | |
files: Record<string, { dependsOn: string[] }>; | |
} | null { |
export async function saveGeneratedCode( | ||
filePath: string, | ||
content: string, | ||
): Promise<string> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add input validation and security checks
The function needs input validation and security measures to prevent potential vulnerabilities.
+import { normalize, isAbsolute } from 'path';
+
+const MAX_FILE_SIZE = 10 * 1024 * 1024; // 10MB limit
+const ALLOWED_EXTENSIONS = ['.ts', '.js', '.json', '.md'];
+
export async function saveGeneratedCode(
filePath: string,
content: string,
): Promise<string> {
+ // Input validation
+ if (!filePath || typeof filePath !== 'string') {
+ throw new Error('Invalid filePath: must be a non-empty string');
+ }
+ if (!content || typeof content !== 'string') {
+ throw new Error('Invalid content: must be a non-empty string');
+ }
+
+ // Security checks
+ const normalizedPath = normalize(filePath);
+ if (isAbsolute(normalizedPath)) {
+ throw new Error('Absolute paths are not allowed');
+ }
+ if (normalizedPath.includes('..')) {
+ throw new Error('Path traversal is not allowed');
+ }
+ if (!ALLOWED_EXTENSIONS.some(ext => normalizedPath.endsWith(ext))) {
+ throw new Error('Invalid file extension');
+ }
+ if (Buffer.byteLength(content, 'utf8') > MAX_FILE_SIZE) {
+ throw new Error('File size exceeds maximum limit');
+ }
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
export async function saveGeneratedCode( | |
filePath: string, | |
content: string, | |
): Promise<string> { | |
import { normalize, isAbsolute } from 'path'; | |
const MAX_FILE_SIZE = 10 * 1024 * 1024; // 10MB limit | |
const ALLOWED_EXTENSIONS = ['.ts', '.js', '.json', '.md']; | |
export async function saveGeneratedCode( | |
filePath: string, | |
content: string, | |
): Promise<string> { | |
// Input validation | |
if (!filePath || typeof filePath !== 'string') { | |
throw new Error('Invalid filePath: must be a non-empty string'); | |
} | |
if (!content || typeof content !== 'string') { | |
throw new Error('Invalid content: must be a non-empty string'); | |
} | |
// Security checks | |
const normalizedPath = normalize(filePath); | |
if (isAbsolute(normalizedPath)) { | |
throw new Error('Absolute paths are not allowed'); | |
} | |
if (normalizedPath.includes('..')) { | |
throw new Error('Path traversal is not allowed'); | |
} | |
if (!ALLOWED_EXTENSIONS.some(ext => normalizedPath.endsWith(ext))) { | |
throw new Error('Invalid file extension'); | |
} | |
if (Buffer.byteLength(content, 'utf8') > MAX_FILE_SIZE) { | |
throw new Error('File size exceeds maximum limit'); | |
} |
it('should return a valid root directory', () => { | ||
const rootDir = getRootDir(); | ||
expect(rootDir).toBeDefined(); | ||
expect(rootDir).toContain('.codefox'); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Add edge case tests
The current test suite lacks coverage for important edge cases.
it('should handle special characters in project ID', () => {
const projectId = 'test@project#123';
const projectPath = getProjectPath(projectId);
expect(projectPath).toBeDefined();
expect(path.basename(projectPath)).toBe(encodeURIComponent(projectId));
});
it('should handle empty or invalid inputs', () => {
expect(() => getProjectPath('')).toThrow();
expect(() => getProjectPath(null)).toThrow();
expect(() => getProjectPath(undefined)).toThrow();
});
Also applies to: 36-40, 42-47
const cleanUp = () => { | ||
// if (existsSync(ROOT_DIR)) { | ||
// rmdirSync(ROOT_DIR, { recursive: true }); | ||
// } | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uncomment cleanup code for proper test isolation
The cleanup function is commented out, which could lead to test pollution.
const cleanUp = () => {
- // if (existsSync(ROOT_DIR)) {
- // rmdirSync(ROOT_DIR, { recursive: true });
- // }
+ if (existsSync(ROOT_DIR)) {
+ rmdirSync(ROOT_DIR, { recursive: true });
+ }
};
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
const cleanUp = () => { | |
// if (existsSync(ROOT_DIR)) { | |
// rmdirSync(ROOT_DIR, { recursive: true }); | |
// } | |
}; | |
const cleanUp = () => { | |
if (existsSync(ROOT_DIR)) { | |
rmdirSync(ROOT_DIR, { recursive: true }); | |
} | |
}; |
async function generateAndSaveCode() { | ||
const generatedCode = ` | ||
import { Controller, Get } from '@nestjs/common'; | ||
@Controller('example') | ||
export class ExampleController { | ||
@Get() | ||
getHello(): string { | ||
return 'Hello World!'; | ||
} | ||
} | ||
`; | ||
|
||
const fileName = 'example.controller.ts'; | ||
|
||
try { | ||
const filePath = await saveGeneratedCode(fileName, generatedCode); | ||
console.log(`Generated code saved at: ${filePath}`); | ||
} catch (error) { | ||
console.error('Failed to save generated code:', error); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix unsafe path handling in generateAndSaveCode
The function uses a hardcoded filename without proper path resolution.
async function generateAndSaveCode() {
const generatedCode = `
import { Controller, Get } from '@nestjs/common';
@Controller('example')
export class ExampleController {
@Get()
getHello(): string {
return 'Hello World!';
}
}
`;
const fileName = 'example.controller.ts';
+ const filePath = path.join(getRootDir(), 'generated', fileName);
try {
- const filePath = await saveGeneratedCode(fileName, generatedCode);
+ const savedPath = await saveGeneratedCode(filePath, generatedCode);
- console.log(`Generated code saved at: ${filePath}`);
+ console.log(`Generated code saved at: ${savedPath}`);
} catch (error) {
- console.error('Failed to save generated code:', error);
+ console.error(`Failed to save generated code to ${filePath}:`, error);
throw error; // Re-throw to fail the test
}
}
Committable suggestion skipped: line range outside the PR's diff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🔭 Outside diff range comments (1)
backend/src/build-system/handlers/file-manager/file-generate/index.ts (1)
The virtual directory is only used for validation, not for file generation
The code review reveals an issue: while the
FileGeneratorHandler
uses the virtual directory to validate file paths (isValidFile
), it doesn't update the virtual directory structure when new files are generated. This means the virtual directory won't reflect the actual file system changes, which could lead to inconsistencies in subsequent operations.Key issues:
- The
VirtualDirectory
class is only used for validation viaisValidFile
method- After
createFile
is called, there's no corresponding update to the virtual directory structure- The virtual directory will become out of sync with the actual file system
The code should be updated to maintain consistency between the virtual directory and the actual file system by adding appropriate calls to update the virtual directory after file creation.
🔗 Analysis chain
Line range hint
1-180
: Verify the impact of file generation on the virtual directory.The file generation process should be reflected in the virtual directory structure.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for virtual directory updates after file generation ast-grep --pattern 'virtualDir.$$$update$$$'Length of output: 46
Script:
#!/bin/bash # Let's search for any method calls or modifications to virtualDir ast-grep --pattern 'this.virtualDir.$_($_)' # Also search for any direct assignments or modifications ast-grep --pattern 'this.virtualDir = $_' # Let's also check the VirtualDirectory class implementation rg -A 5 "class VirtualDirectory"Length of output: 764
Script:
#!/bin/bash # Let's check the VirtualDirectory class methods rg -A 10 "class VirtualDirectory" backend/src/build-system/virtual-dir/index.ts # Check for methods that modify the virtual directory ast-grep --pattern 'class VirtualDirectory { $$$ add$_($$$) { $$$ } $$$ }' # Also check for update methods ast-grep --pattern 'class VirtualDirectory { $$$ update$_($$$) { $$$ } $$$ }'Length of output: 439
Script:
#!/bin/bash # Let's check the entire VirtualDirectory implementation cat backend/src/build-system/virtual-dir/index.ts # Also check if there are any other handlers that modify the virtual directory rg -l "virtualDirectory" backend/src/build-system/handlers/Length of output: 3168
🧹 Nitpick comments (2)
backend/src/build-system/handlers/file-manager/file-generate/index.ts (2)
41-41
: Address TODO comment and enhance file content generation.
- The TODO comment needs to be addressed.
- The createFile method currently uses placeholder content, which may not be the intended behavior.
Would you like me to help implement proper file content generation logic or create an issue to track this task?
Also applies to: 54-57
Line range hint
41-64
: Consider enhancing error handling and logging.The file generation process could benefit from:
- More detailed error messages in case of file system operations failure
- Structured logging of the generation process
- Rollback mechanism in case of partial failure
async generateFiles( markdownContent: string, projectSrcPath: string, ): Promise<{ success: boolean; data: string }> { + const generatedFiles: string[] = []; + try { const jsonData = extractJsonFromMarkdown(markdownContent); // Build the dependency graph and detect cycles before any file operations const { graph, nodes } = this.buildDependencyGraph(jsonData); this.detectCycles(graph); // Add virtual directory validation this.validateAgainstVirtualDirectory(nodes); // After validation and cycle detection, perform topological sort const sortedFiles = this.getSortedFiles(graph, nodes); // Generate files in the correct order for (const file of sortedFiles) { const fullPath = normalizePath(path.resolve(projectSrcPath, file)); this.logger.log(`Generating file in dependency order: ${fullPath}`); await this.createFile(fullPath); + generatedFiles.push(fullPath); } this.logger.log('All files generated successfully.'); return { success: true, data: 'Files and dependencies created successfully.', }; + } catch (error) { + this.logger.error(`File generation failed: ${error.message}`); + // Attempt to clean up generated files + for (const file of generatedFiles) { + try { + await fs.unlink(file); + } catch (cleanupError) { + this.logger.error(`Failed to clean up file ${file}: ${cleanupError.message}`); + } + } + throw error; + } }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
backend/src/build-system/handlers/file-manager/file-generate/index.ts
(3 hunks)backend/src/build-system/hanlder-manager.ts
(2 hunks)
🔇 Additional comments (2)
backend/src/build-system/hanlder-manager.ts (1)
12-12
: LGTM! Handler registration looks good.
The FileGeneratorHandler is properly imported and registered following the existing pattern.
Also applies to: 34-34
backend/src/build-system/handlers/file-manager/file-generate/index.ts (1)
8-10
: LGTM! Good improvements to type safety and utilities.
The implementation of BuildHandler interface and addition of necessary utilities enhance the code structure.
Also applies to: 12-13
const uuid = context.getData('projectUUID'); | ||
|
||
const projectSrcPath = getProjectPath(uuid); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add error handling for invalid UUID.
The UUID retrieval lacks validation and error handling. Consider adding checks to ensure the UUID exists and is valid.
- const uuid = context.getData('projectUUID');
- const projectSrcPath = getProjectPath(uuid);
+ const uuid = context.getData('projectUUID');
+ if (!uuid) {
+ throw new Error('Project UUID is required but was not provided in context');
+ }
+ const projectSrcPath = getProjectPath(uuid);
+ if (!projectSrcPath) {
+ throw new Error(`Could not resolve project path for UUID: ${uuid}`);
+ }
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
const uuid = context.getData('projectUUID'); | |
const projectSrcPath = getProjectPath(uuid); | |
const uuid = context.getData('projectUUID'); | |
if (!uuid) { | |
throw new Error('Project UUID is required but was not provided in context'); | |
} | |
const projectSrcPath = getProjectPath(uuid); | |
if (!projectSrcPath) { | |
throw new Error(`Could not resolve project path for UUID: ${uuid}`); | |
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think bot provides useful review
Summary by CodeRabbit
New Features
FileGeneratorHandler
for file generation processes.Bug Fixes
Chores