mirror of
https://github.com/DumbWareio/DumbDrop.git
synced 2025-10-22 23:31:57 +00:00
22f79f830b
Chores & Configuration • Enhanced development setup: optimized Dockerfile, refined scripts, and improved .gitignore. • Updated docker-compose for better dev/prod separation. • Improved documentation in README and source files. Features & Enhancements • Refactored project structure with modular architecture. • Improved testing infrastructure and integration tests. • Enhanced file upload logic, client-side handling, and API routes. • Implemented robust server shutdown, rate limiting, and cleanup mechanisms. • Improved upload progress tracking with UI enhancements. • Strengthened security in PIN authentication and cookie handling. Refactors & Fixes • Cleaned up test infrastructure, logging, and error handling. • Simplified API route paths and improved middleware. • Fixed incorrect total storage size reporting. • Optimized logging verbosity based on environment. Documentation • Expanded project documentation and comments for clarity.
130 lines
4.2 KiB
Plaintext
130 lines
4.2 KiB
Plaintext
/**
|
|
* Cursor rules for maintaining code quality and consistency
|
|
*/
|
|
|
|
{
|
|
"rules": {
|
|
"file-header-docs": {
|
|
"description": "All source files must have a header comment explaining their purpose",
|
|
"pattern": "src/**/*.js",
|
|
"check": {
|
|
"type": "regex",
|
|
"value": "^/\\*\\*\\n \\* [^\\n]+\\n \\* [^\\n]+\\n \\* [^\\n]+\\n \\*/\\n",
|
|
"message": "File must start with a header comment block (3 lines) explaining its purpose"
|
|
}
|
|
}
|
|
}
|
|
}
|
|
|
|
# Project Principles
|
|
|
|
# Code Philosophy
|
|
- Keep code simple, smart, and follow best practices
|
|
- Don't over-engineer for the sake of engineering
|
|
- Use standard conventions and patterns
|
|
- Write human-readable code
|
|
- Keep it simple so the app just works
|
|
- Follow the principle: "Make it work, make it right, make it fast"
|
|
- Comments should explain "why" behind the code in more complex functions
|
|
- Overcommented code is better than undercommented code
|
|
|
|
# Commit Conventions
|
|
- Use Conventional Commits format:
|
|
- feat: new features
|
|
- fix: bug fixes
|
|
- docs: documentation changes
|
|
- style: formatting, missing semi colons, etc.
|
|
- refactor: code changes that neither fix bugs nor add features
|
|
- test: adding or modifying tests
|
|
- chore: updating build tasks, package manager configs, etc.
|
|
- Each commit should be atomic and focused
|
|
- Write clear, descriptive commit messages
|
|
|
|
# Project Structure
|
|
|
|
# Root Directory
|
|
- Keep root directory clean with only essential files
|
|
- Production configuration files in root:
|
|
- docker-compose.yml
|
|
- Dockerfile
|
|
- .env.example
|
|
- package.json
|
|
- README.md
|
|
|
|
# Source Code (/src)
|
|
- All application source code in /src directory
|
|
- app.js: Application setup and configuration
|
|
- server.js: Server entry point
|
|
- routes/: Route handlers
|
|
- middleware/: Custom middleware
|
|
- utils/: Helper functions and utilities
|
|
- models/: Data models (if applicable)
|
|
- services/: Business logic
|
|
|
|
# Development
|
|
- All development configurations in /dev directory
|
|
- Development specific files:
|
|
- /dev/docker-compose.dev.yml
|
|
- /dev/.env.dev.example
|
|
- /dev/README.md (development setup instructions)
|
|
|
|
# Static Assets and Uploads
|
|
- Static assets in /public directory
|
|
- Upload directories:
|
|
- /uploads (production)
|
|
- /local_uploads (local development)
|
|
|
|
# Testing
|
|
- Tests are mandatory for all new features
|
|
- Test files location:
|
|
- Unit tests: __tests__/unit/
|
|
- Integration tests: __tests__/integration/
|
|
- E2E tests: __tests__/e2e/
|
|
- Test naming convention:
|
|
- Unit tests: [feature].test.js
|
|
- Integration tests: [feature].integration.test.js
|
|
- E2E tests: [feature].e2e.test.js
|
|
- Test coverage requirements:
|
|
- Minimum 80% coverage for new features
|
|
- Must include happy path and error cases
|
|
- API endpoints must have integration tests
|
|
|
|
# Documentation
|
|
- Main README.md in root focuses on production deployment
|
|
- Development documentation in /dev/README.md
|
|
- Code must be self-documenting with clear naming
|
|
- Complex logic must include comments explaining "why" not "what"
|
|
- JSDoc comments for public functions and APIs
|
|
|
|
# Docker Configuration
|
|
- Use environment-specific .dockerignore files:
|
|
- .dockerignore: Production defaults (most restrictive)
|
|
- dev/.dockerignore: Development-specific (allows test/dev files)
|
|
- Production .dockerignore should exclude:
|
|
- All test files and configurations
|
|
- Development-only dependencies
|
|
- Documentation and non-essential files
|
|
- Local development configurations
|
|
- Development .dockerignore should:
|
|
- Allow test files and configurations
|
|
- Allow development dependencies
|
|
- Still exclude node_modules and sensitive files
|
|
- Keep Docker-specific files excluded
|
|
- Docker Compose configurations:
|
|
- Production: docker-compose.yml in root
|
|
- Development: docker-compose.dev.yml in /dev
|
|
- Use BuildKit features when needed
|
|
- Document any special build arguments
|
|
- Multi-stage builds:
|
|
- Use appropriate base images
|
|
- Minimize final image size
|
|
- Separate development and production stages
|
|
- Use specific version tags for base images
|
|
|
|
# Code Style
|
|
- Follow ESLint and Prettier configurations
|
|
- Use meaningful variable and function names
|
|
- Keep functions small and focused
|
|
- Maximum line length: 100 characters
|
|
- Use modern JavaScript features appropriately
|
|
- Prefer clarity over cleverness |