-
Notifications
You must be signed in to change notification settings - Fork 3
Feat(backend) file structure #59
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
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 -->
WalkthroughA new class Changes
Possibly related PRs
Suggested reviewers
Poem
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/node/frontend-file-structure/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. 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: 8
🧹 Outside diff range and nitpick comments (4)
backend/src/build-system/node/file-structure/index.ts (1)
3-3
: Remove unused importModelProvider
The
ModelProvider
import is not used in this file.-import { ModelProvider } from 'src/common/model-provider';
backend/src/build-system/node/file-structure/prompt.ts (3)
2-7
: Fix parameter naming conventionThe parameter
DataAnalysisDoc
uses PascalCase while other parameters use camelCase. Maintain consistency by using camelCase for all parameters.generateFileStructurePrompt: ( projectName: string, sitemapDoc: string, - DataAnalysisDoc: string, + dataAnalysisDoc: string, framework: string, ): string => {
51-53
: Fix grammatical errors in instructionsThere are several grammatical errors in the self-check section that should be corrected for clarity.
- 1, Are you consider all the cases based on the sitemap doc? If not add new folder or file - -This final result must be 100% complete. Will be directly use in the production + 1. Have you considered all the cases based on the sitemap doc? If not, add necessary folders or files. + +This final result must be 100% complete as it will be used directly in production.
50-51
: Enhance the self-check sectionThe self-check section could be more comprehensive to ensure all requirements are met.
Consider adding more validation points:
Self check: - 1, Are you consider all the cases based on the sitemap doc? If not add new folder or file + 1. Have you considered all the cases based on the sitemap doc? + 2. Does the structure align with the data analysis requirements? + 3. Are all framework-specific conventions followed? + 4. Is the folder structure scalable for future additions? + 5. Are all necessary state management and API integration folders included?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
backend/src/build-system/node/file-structure/index.ts
(1 hunks)backend/src/build-system/node/file-structure/prompt.ts
(1 hunks)
🔇 Additional comments (1)
backend/src/build-system/node/file-structure/index.ts (1)
24-29
: 🛠️ Refactor suggestion
Improve model configuration handling
The model name 'gpt-4o-mini' is hardcoded. Consider making it configurable through the context or environment variables.
- 'gpt-4o-mini',
+ context.config.defaultModel || process.env.DEFAULT_MODEL || 'gpt-4o-mini',
return { | ||
success: true, | ||
data: fileStructureContent, | ||
}; | ||
} |
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.
Enhance error handling
The method always returns success: true
without proper error handling. Consider adding try-catch blocks and proper error handling.
+ try {
const fileStructureContent = await context.model.chatSync(
{
content: prompt,
},
'gpt-4o-mini',
);
return {
success: true,
data: fileStructureContent,
};
+ } catch (error) {
+ return {
+ success: false,
+ error: `Failed to generate file structure: ${error.message}`,
+ };
+ }
Committable suggestion skipped: line range outside the PR's diff.
import { prompts } from './prompt'; | ||
|
||
export class FileStructureHandler implements BuildHandler { | ||
readonly id = 'op:File_Structure::STATE:GENERATE'; |
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.
💡 Codebase verification
Handler ID format needs standardization
The ID format is inconsistent across handlers. Current variations found:
op:File_Structure::STATE:GENERATE
op:DATABASE_REQ::STATE:GENERATE
op:PROJECT::STATE:SETUP
OP:DATABASE:SCHEMAS
op:PRD::STATE:GENERATE
Issues:
- Inconsistent capitalization (
op
vsOP
) - Varying separator usage (
:
vs::
) - Inconsistent word separators (underscore vs none)
- Some IDs use
STATE:
prefix while others don't
🔗 Analysis chain
Verify the handler ID format
The ID format op:File_Structure::STATE:GENERATE
appears to follow a specific pattern. Ensure it matches the expected format used across other handlers in the system.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other handler IDs to verify consistent formatting
rg -g '*.ts' 'readonly id = ' --type typescript
Length of output: 84
Script:
#!/bin/bash
# Search for other handler IDs to verify consistent formatting
rg 'readonly id = ' -A 1
Length of output: 1716
args as string, | ||
// TODO: change later | ||
args as string, | ||
'FrameWork Holder', |
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.
Improve type safety and args handling
The code casts args
to string twice without validation, which could lead to runtime errors.
- args as string,
- // TODO: change later
- args as string,
+ typeof args === 'string' ? args : '',
+ typeof args === 'string' ? args : '',
Also, please clarify the purpose of passing the same argument twice. If they serve different purposes, consider using distinct, well-typed parameters.
Committable suggestion skipped: line range outside the PR's diff.
args as string, | ||
// TODO: change later | ||
args as string, | ||
'FrameWork Holder', |
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.
💡 Codebase verification
Framework value should be retrieved from context
The hardcoded 'FrameWork Holder' is indeed a placeholder that should be replaced. The codebase shows that framework values are properly managed through context in other files (e.g., backend-requirements-document/index.ts uses context.getData('framework')
). You should:
- Replace
'FrameWork Holder'
withcontext.getData('framework') || 'express'
to maintain consistency with the rest of the codebase - The default value 'express' is suggested based on the existing pattern in backend-requirements-document/index.ts
🔗 Analysis chain
Replace hardcoded framework value
The value 'FrameWork Holder' appears to be a placeholder. Consider making this configurable or deriving it from the context.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if framework information is available in the context elsewhere
rg -g '*.ts' 'framework' --type typescript -A 5 -B 5
Length of output: 87
Script:
#!/bin/bash
# Search for framework-related strings in TypeScript files
rg -g '*.ts' -i 'framework'
# Also check the specific file content
cat backend/src/build-system/node/file-structure/index.ts
Length of output: 2790
For components, include an index.tsx file in each folder to simplify imports. | ||
Each component should have its own folder named after the component (e.g., Button/). | ||
Use index.tsx as the main file inside the component folder. | ||
Component-specific styles must be in index.css within the same folder as the component. |
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
Make file extensions framework-specific
The template assumes .tsx
extensions, which is specific to TypeScript React projects. This should be dynamic based on the framework parameter.
Consider adapting the file extensions:
- For components, include an index.tsx file in each folder to simplify imports.
- Each component should have its own folder named after the component (e.g., Button/).
- Use index.tsx as the main file inside the component folder.
+ For components, include an index file with the appropriate extension (e.g., .tsx for React TypeScript, .vue for Vue, .svelte for Svelte) in each folder to simplify imports.
+ Each component should have its own folder named after the component (e.g., Button/).
+ Use index with the framework-appropriate extension as the main file inside the component folder.
📝 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.
For components, include an index.tsx file in each folder to simplify imports. | |
Each component should have its own folder named after the component (e.g., Button/). | |
Use index.tsx as the main file inside the component folder. | |
Component-specific styles must be in index.css within the same folder as the component. | |
For components, include an index file with the appropriate extension (e.g., .tsx for React TypeScript, .vue for Vue, .svelte for Svelte) in each folder to simplify imports. | |
Each component should have its own folder named after the component (e.g., Button/). | |
Use index with the framework-appropriate extension as the main file inside the component folder. | |
Component-specific styles must be in index.css within the same folder as the component. |
return `You are an expert frontend developer. Your task is to generate a complete folder and file structure for the src directory of a frontend project. Include all necessary files and folders to cover UI, API calls, and local state management while ensuring scalability and maintainability. | ||
Based on following input | ||
|
||
- Project name: ${projectName} | ||
- Sitemap Documentation: ${sitemapDoc} | ||
- Data Analysis Doc ${DataAnalysisDoc} | ||
|
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.
Utilize the framework parameter in the template
The framework
parameter is not being used in the template string. This could lead to incorrect file extensions and framework-specific folder structures being generated.
Consider adapting the template based on the framework:
return `You are an expert frontend developer. Your task is to generate a complete folder and file structure for the src directory of a frontend project. Include all necessary files and folders to cover UI, API calls, and local state management while ensuring scalability and maintainability.
Based on following input
- Project name: ${projectName}
- Sitemap Documentation: ${sitemapDoc}
- Data Analysis Doc ${DataAnalysisDoc}
+ - Framework: ${framework}
📝 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.
return `You are an expert frontend developer. Your task is to generate a complete folder and file structure for the src directory of a frontend project. Include all necessary files and folders to cover UI, API calls, and local state management while ensuring scalability and maintainability. | |
Based on following input | |
- Project name: ${projectName} | |
- Sitemap Documentation: ${sitemapDoc} | |
- Data Analysis Doc ${DataAnalysisDoc} | |
return `You are an expert frontend developer. Your task is to generate a complete folder and file structure for the src directory of a frontend project. Include all necessary files and folders to cover UI, API calls, and local state management while ensuring scalability and maintainability. | |
Based on following input | |
- Project name: ${projectName} | |
- Sitemap Documentation: ${sitemapDoc} | |
- Data Analysis Doc ${DataAnalysisDoc} | |
- Framework: ${framework} | |
export const prompts = { | ||
generateFileStructurePrompt: ( | ||
projectName: string, | ||
sitemapDoc: string, | ||
DataAnalysisDoc: string, | ||
framework: string, | ||
): string => { | ||
return `You are an expert frontend developer. Your task is to generate a complete folder and file structure for the src directory of a frontend project. Include all necessary files and folders to cover UI, API calls, and local state management while ensuring scalability and maintainability. | ||
Based on following input | ||
|
||
- Project name: ${projectName} | ||
- Sitemap Documentation: ${sitemapDoc} | ||
- Data Analysis Doc ${DataAnalysisDoc} | ||
|
||
### Instructions and Rules: | ||
|
||
Include: | ||
Folder Structure: | ||
components: Reusable UI elements grouped by category (e.g., common, layout, specific). | ||
contexts: Global state management (e.g., auth, theme, player). | ||
hooks: Custom hooks for data fetching and state management. | ||
pages: Route-specific views (e.g., Home, Search, Playlist). | ||
utils: Utility functions (e.g., constants, helpers, validators). | ||
api: Organized API logic (e.g., auth, music, user). | ||
router.ts: Central routing configuration. | ||
index.ts: Application entry point. | ||
|
||
Files: | ||
Include placeholder files in each folder to illustrate their purpose. | ||
Add example filenames for components, hooks, APIs, etc. | ||
|
||
Do Not Include: | ||
|
||
Asset folders (e.g., images, icons, fonts). | ||
Test folders or files. | ||
Service folders unrelated to API logic. | ||
|
||
File Naming Guidelines: | ||
|
||
Use meaningful and descriptive file names. | ||
For components, include an index.tsx file in each folder to simplify imports. | ||
Each component should have its own folder named after the component (e.g., Button/). | ||
Use index.tsx as the main file inside the component folder. | ||
Component-specific styles must be in index.css within the same folder as the component. | ||
|
||
File Comments: | ||
|
||
Include comments describing the purpose of each file or folder to improve readability. | ||
|
||
Self check: | ||
1, Are you consider all the cases based on the sitemap doc? If not add new folder or file | ||
|
||
This final result must be 100% complete. Will be directly use in the production | ||
|
||
Output Format: | ||
|
||
Start with: "\`\`\`FolderStructure" | ||
Tree format: | ||
Include folder names with placeholder/example files inside. | ||
Add comments to describe the purpose of each file/folder. | ||
End with: "\`\`\`" | ||
`; | ||
}, | ||
}; |
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.
💡 Codebase verification
Prompt integration needs attention - missing required parameter
The verification revealed that the prompt is being used in backend/src/build-system/node/file-structure/index.ts
, but there's a mismatch in the parameters being passed:
- The prompt definition requires 4 parameters:
projectName
,sitemapDoc
,DataAnalysisDoc
, andframework
- The actual usage only passes 3 arguments:
projectName
,args
, and a TODO comment - The
framework
parameter is completely missing in the implementation
🔗 Analysis chain
Verify prompt integration with FileStructureHandler
Let's verify that this prompt is properly integrated with the FileStructureHandler class.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the integration of the prompt with FileStructureHandler
# Check how the prompt is imported and used
rg -t typescript "generateFileStructurePrompt" --context 3
# Verify that all required parameters are passed when called
ast-grep --pattern 'generateFileStructurePrompt($$$)'
Length of output: 149
Script:
#!/bin/bash
# Let's try different approaches to find the usage
# Search for the prompt file and its imports
rg "prompt.ts" -A 3 -B 3
# Search for any file structure related files
fd "file-structure" --type f
# Search for the specific function name without file type restriction
rg "generateFileStructurePrompt" -A 3 -B 3
# Look for potential handler files
fd "handler" --type f
Length of output: 2172
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: 5
🧹 Outside diff range and nitpick comments (5)
backend/src/build-system/node/frontend-file-structure/index.ts (2)
9-14
: Replace console.log with proper logging systemConsider using a structured logging system instead of console.log for better observability and consistency with production standards.
- console.log('Generating File Structure Document...'); + context.logger.info('Generating File Structure Document...');
28-28
: Consider making the model name configurableThe model name 'gpt-4o-mini' is hardcoded. Consider making it configurable through context or environment variables.
- 'gpt-4o-mini', + context.config.get('fileStructure.modelName', 'gpt-4o-mini'),backend/src/build-system/node/frontend-file-structure/prompt.ts (3)
1-7
: Improve method signature documentation and naming conventions.
- The parameter
DataAnalysisDoc
should follow camelCase naming convention.- Consider adding JSDoc documentation for better code documentation and IDE support.
export const prompts = { + /** + * Generates a prompt for creating frontend project file structure + * @param projectName - Name of the frontend project + * @param sitemapDoc - Documentation of the site structure + * @param dataAnalysisDoc - Documentation of data analysis + * @param framework - Frontend framework being used + * @returns Formatted prompt string for file structure generation + */ generateFileStructurePrompt: ( projectName: string, sitemapDoc: string, - DataAnalysisDoc: string, + dataAnalysisDoc: string, framework: string, ): string => {
51-51
: Fix grammatical errors in self-check question.The self-check question contains grammatical errors that could cause confusion.
- 1, Are you consider all the cases based on the sitemap doc? If not add new folder or file + 1. Have you considered all cases based on the sitemap doc? If not, add necessary folders or files.
57-61
: Consider escaping backticks in template literal.The backticks used for the output format markers are escaped using backslashes, but template literals provide a cleaner way to include backticks.
- Start with: "\`\`\`FolderStructure" - Tree format: - Include folder names with placeholder/example files inside. - Add comments to describe the purpose of each file/folder. - End with: "\`\`\`" + Start with: ${"`".repeat(3)}FolderStructure + Tree format: + Include folder names with placeholder/example files inside. + Add comments to describe the purpose of each file/folder. + End with: ${"`".repeat(3)}
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
backend/src/build-system/node/frontend-file-structure/index.ts
(1 hunks)backend/src/build-system/node/frontend-file-structure/prompt.ts
(1 hunks)
const prompt = prompts.generateFileStructurePrompt( | ||
projectName, | ||
args as string, | ||
// TODO: change later | ||
args as string, | ||
'FrameWork Holder', | ||
); |
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.
Improve type safety and remove hardcoded values
Several issues in this code segment need attention:
- Unsafe type casting of
args
- Hardcoded framework value
- TODO comment needs addressing
Consider this safer implementation:
+ interface FileStructureArgs {
+ sitemapDoc: string;
+ dataAnalysisDoc: string;
+ framework: string;
+ }
+
+ if (!args || typeof args !== 'object') {
+ throw new Error('Invalid arguments provided to FileStructureHandler');
+ }
+
+ const typedArgs = args as FileStructureArgs;
+
const prompt = prompts.generateFileStructurePrompt(
projectName,
- args as string,
- // TODO: change later
- args as string,
- 'FrameWork Holder',
+ typedArgs.sitemapDoc,
+ typedArgs.dataAnalysisDoc,
+ typedArgs.framework,
);
📝 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 prompt = prompts.generateFileStructurePrompt( | |
projectName, | |
args as string, | |
// TODO: change later | |
args as string, | |
'FrameWork Holder', | |
); | |
interface FileStructureArgs { | |
sitemapDoc: string; | |
dataAnalysisDoc: string; | |
framework: string; | |
} | |
if (!args || typeof args !== 'object') { | |
throw new Error('Invalid arguments provided to FileStructureHandler'); | |
} | |
const typedArgs = args as FileStructureArgs; | |
const prompt = prompts.generateFileStructurePrompt( | |
projectName, | |
typedArgs.sitemapDoc, | |
typedArgs.dataAnalysisDoc, | |
typedArgs.framework, | |
); |
import { BuildHandler, BuildResult } from 'src/build-system/types'; | ||
import { BuilderContext } from 'src/build-system/context'; | ||
import { ModelProvider } from 'src/common/model-provider'; | ||
import { prompts } from './prompt'; | ||
|
||
export class FileStructureHandler implements BuildHandler { | ||
readonly id = 'op:File_Structure::STATE:GENERATE'; |
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.
💡 Codebase verification
Operation ID format needs standardization
The operation IDs in the codebase show inconsistencies in their format:
- Some use uppercase
OP:
prefix while others use lowercaseop:
- Some use underscores in operation names (
File_Structure
,UX_Structure
) while others use plain uppercase (PRD
,UXSMD
) - Some use double colons
::
as separators while others use single colon:
- The
STATE:
segment is present in some IDs but missing in others
Examples of inconsistencies:
OP:DATABASE:SCHEMAS
vsop:File_Structure::STATE:GENERATE
op:UX_Structure::STATE:GENERATE
vsop:UXSMD::STATE:GENERATE
op:PROJECT::STATE:SETUP
vsOP:DATABASE:SCHEMAS
🔗 Analysis chain
Verify the operation ID format consistency
The operation ID op:File_Structure::STATE:GENERATE
follows a specific format. Let's verify this format is consistent with other handlers in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other operation IDs to verify format consistency
rg -g '*.ts' 'readonly id = .*' --no-filename | sort -u
Length of output: 479
const fileStructureContent = await context.model.chatSync( | ||
{ | ||
content: prompt, | ||
}, | ||
'gpt-4o-mini', | ||
); | ||
return { | ||
success: true, | ||
data: fileStructureContent, | ||
}; | ||
} |
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 and input validation
The model interaction lacks error handling and the response isn't validated before returning.
Consider this improved implementation:
+ if (!prompt) {
+ throw new Error('Failed to generate prompt for file structure');
+ }
+
+ try {
const fileStructureContent = await context.model.chatSync(
{
content: prompt,
},
'gpt-4o-mini',
);
+
+ if (!fileStructureContent) {
+ throw new Error('No content generated by the model');
+ }
+
return {
success: true,
data: fileStructureContent,
};
+ } catch (error) {
+ context.logger.error('Failed to generate file structure', { error });
+ return {
+ success: false,
+ error: error instanceof Error ? error.message : 'Unknown error occurred',
+ };
+ }
Committable suggestion skipped: line range outside the PR's diff.
Use meaningful and descriptive file names. | ||
For components, include an index.tsx file in each folder to simplify imports. | ||
Each component should have its own folder named after the component (e.g., Button/). | ||
Use index.tsx as the main file inside the component folder. | ||
Component-specific styles must be in index.css within the same folder as the component. |
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.
Make file extensions framework-agnostic.
The file naming guidelines assume React with TypeScript (.tsx
), but this should be dynamic based on the framework parameter.
Use meaningful and descriptive file names.
- For components, include an index.tsx file in each folder to simplify imports.
+ For components, include an index.${fileExtension} file in each folder to simplify imports.
Each component should have its own folder named after the component (e.g., Button/).
- Use index.tsx as the main file inside the component folder.
+ Use index.${fileExtension} as the main file inside the component folder.
Committable suggestion skipped: line range outside the PR's diff.
return `You are an expert frontend developer. Your task is to generate a complete folder and file structure for the src directory of a frontend project. Include all necessary files and folders to cover UI, API calls, and local state management while ensuring scalability and maintainability. | ||
Based on following input | ||
|
||
- Project name: ${projectName} | ||
- Sitemap Documentation: ${sitemapDoc} | ||
- Data Analysis Doc ${DataAnalysisDoc} | ||
|
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 parameter validation and utilize the framework parameter.
- The
framework
parameter is not being used in the template, which could lead to incorrect file extensions. - Consider adding validation for empty or undefined parameters.
): string => {
+ if (!projectName || !sitemapDoc || !dataAnalysisDoc || !framework) {
+ throw new Error('All parameters are required for generating file structure prompt');
+ }
+ const fileExtension = framework.toLowerCase().includes('react') ? 'tsx' : 'js';
return `You are an expert frontend developer. Your task is to generate a complete folder and file structure for the src directory of a frontend project. Include all necessary files and folders to cover UI, API calls, and local state management while ensuring scalability and maintainability.
📝 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.
return `You are an expert frontend developer. Your task is to generate a complete folder and file structure for the src directory of a frontend project. Include all necessary files and folders to cover UI, API calls, and local state management while ensuring scalability and maintainability. | |
Based on following input | |
- Project name: ${projectName} | |
- Sitemap Documentation: ${sitemapDoc} | |
- Data Analysis Doc ${DataAnalysisDoc} | |
if (!projectName || !sitemapDoc || !dataAnalysisDoc || !framework) { | |
throw new Error('All parameters are required for generating file structure prompt'); | |
} | |
const fileExtension = framework.toLowerCase().includes('react') ? 'tsx' : 'js'; | |
return `You are an expert frontend developer. Your task is to generate a complete folder and file structure for the src directory of a frontend project. Include all necessary files and folders to cover UI, API calls, and local state management while ensuring scalability and maintainability. | |
Based on following input | |
- Project name: ${projectName} | |
- Sitemap Documentation: ${sitemapDoc} | |
- Data Analysis Doc ${DataAnalysisDoc} | |
<!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Introduced a new `FileStructureHandler` class to manage file structure generation for frontend projects. - Added a prompt generation method that outlines the folder and file structure for the `src` directory, including specific guidelines for organization and naming conventions. - **Documentation** - Enhanced documentation for the new prompt generation method to clarify its usage and output format. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Jackson Chen <90215880+Sma1lboy@users.noreply.github.com>
Summary by CodeRabbit
New Features
FileStructureHandler
class to manage file structure generation for frontend projects.src
directory, including specific guidelines for organization and naming conventions.Documentation