cf0f779ad4
This commit introduces the spec-workflow, a set of templates for creating design, product, requirements, and other specification documents. These templates are added to both the root directory and the `apps/frontend` workspace. Additionally, this commit upgrades the frontend development dependencies for the Astro application. The key changes include: - Migration from `@astrojs/tailwind` to `@tailwindcss/vite` for Tailwind CSS integration. - Deletion of the `postcss.config.cjs` file, as it is no longer needed with the new setup. - Updates to `astro.config.mjs` to use the new Vite plugin for Tailwind CSS. - General upgrade of Astro and other related dependencies in `apps/frontend/package.json` and the corresponding `pnpm-lock.yaml` file.
146 lines
4.6 KiB
Markdown
146 lines
4.6 KiB
Markdown
# Project Structure
|
|
|
|
## Directory Organization
|
|
|
|
```
|
|
[Define your project's directory structure. Examples below - adapt to your project type]
|
|
|
|
Example for a library/package:
|
|
project-root/
|
|
├── src/ # Source code
|
|
├── tests/ # Test files
|
|
├── docs/ # Documentation
|
|
├── examples/ # Usage examples
|
|
└── [build/dist/out] # Build output
|
|
|
|
Example for an application:
|
|
project-root/
|
|
├── [src/app/lib] # Main source code
|
|
├── [assets/resources] # Static resources
|
|
├── [config/settings] # Configuration
|
|
├── [scripts/tools] # Build/utility scripts
|
|
└── [tests/spec] # Test files
|
|
|
|
Common patterns:
|
|
- Group by feature/module
|
|
- Group by layer (UI, business logic, data)
|
|
- Group by type (models, controllers, views)
|
|
- Flat structure for simple projects
|
|
```
|
|
|
|
## Naming Conventions
|
|
|
|
### Files
|
|
- **Components/Modules**: [e.g., `PascalCase`, `snake_case`, `kebab-case`]
|
|
- **Services/Handlers**: [e.g., `UserService`, `user_service`, `user-service`]
|
|
- **Utilities/Helpers**: [e.g., `dateUtils`, `date_utils`, `date-utils`]
|
|
- **Tests**: [e.g., `[filename]_test`, `[filename].test`, `[filename]Test`]
|
|
|
|
### Code
|
|
- **Classes/Types**: [e.g., `PascalCase`, `CamelCase`, `snake_case`]
|
|
- **Functions/Methods**: [e.g., `camelCase`, `snake_case`, `PascalCase`]
|
|
- **Constants**: [e.g., `UPPER_SNAKE_CASE`, `SCREAMING_CASE`, `PascalCase`]
|
|
- **Variables**: [e.g., `camelCase`, `snake_case`, `lowercase`]
|
|
|
|
## Import Patterns
|
|
|
|
### Import Order
|
|
1. External dependencies
|
|
2. Internal modules
|
|
3. Relative imports
|
|
4. Style imports
|
|
|
|
### Module/Package Organization
|
|
```
|
|
[Describe your project's import/include patterns]
|
|
Examples:
|
|
- Absolute imports from project root
|
|
- Relative imports within modules
|
|
- Package/namespace organization
|
|
- Dependency management approach
|
|
```
|
|
|
|
## Code Structure Patterns
|
|
|
|
[Define common patterns for organizing code within files. Below are examples - choose what applies to your project]
|
|
|
|
### Module/Class Organization
|
|
```
|
|
Example patterns:
|
|
1. Imports/includes/dependencies
|
|
2. Constants and configuration
|
|
3. Type/interface definitions
|
|
4. Main implementation
|
|
5. Helper/utility functions
|
|
6. Exports/public API
|
|
```
|
|
|
|
### Function/Method Organization
|
|
```
|
|
Example patterns:
|
|
- Input validation first
|
|
- Core logic in the middle
|
|
- Error handling throughout
|
|
- Clear return points
|
|
```
|
|
|
|
### File Organization Principles
|
|
```
|
|
Choose what works for your project:
|
|
- One class/module per file
|
|
- Related functionality grouped together
|
|
- Public API at the top/bottom
|
|
- Implementation details hidden
|
|
```
|
|
|
|
## Code Organization Principles
|
|
|
|
1. **Single Responsibility**: Each file should have one clear purpose
|
|
2. **Modularity**: Code should be organized into reusable modules
|
|
3. **Testability**: Structure code to be easily testable
|
|
4. **Consistency**: Follow patterns established in the codebase
|
|
|
|
## Module Boundaries
|
|
[Define how different parts of your project interact and maintain separation of concerns]
|
|
|
|
Examples of boundary patterns:
|
|
- **Core vs Plugins**: Core functionality vs extensible plugins
|
|
- **Public API vs Internal**: What's exposed vs implementation details
|
|
- **Platform-specific vs Cross-platform**: OS-specific code isolation
|
|
- **Stable vs Experimental**: Production code vs experimental features
|
|
- **Dependencies direction**: Which modules can depend on which
|
|
|
|
## Code Size Guidelines
|
|
[Define your project's guidelines for file and function sizes]
|
|
|
|
Suggested guidelines:
|
|
- **File size**: [Define maximum lines per file]
|
|
- **Function/Method size**: [Define maximum lines per function]
|
|
- **Class/Module complexity**: [Define complexity limits]
|
|
- **Nesting depth**: [Maximum nesting levels]
|
|
|
|
## Dashboard/Monitoring Structure (if applicable)
|
|
[How dashboard or monitoring components are organized]
|
|
|
|
### Example Structure:
|
|
```
|
|
src/
|
|
└── dashboard/ # Self-contained dashboard subsystem
|
|
├── server/ # Backend server components
|
|
├── client/ # Frontend assets
|
|
├── shared/ # Shared types/utilities
|
|
└── public/ # Static assets
|
|
```
|
|
|
|
### Separation of Concerns
|
|
- Dashboard isolated from core business logic
|
|
- Own CLI entry point for independent operation
|
|
- Minimal dependencies on main application
|
|
- Can be disabled without affecting core functionality
|
|
|
|
## Documentation Standards
|
|
- All public APIs must have documentation
|
|
- Complex logic should include inline comments
|
|
- README files for major modules
|
|
- Follow language-specific documentation conventions
|