-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy path.cursorrules
170 lines (139 loc) · 6.89 KB
/
.cursorrules
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
backend prisma is in - cd /Users/john/myapps/colourstream/backend && npx prisma generate
FRONTEND CHANGE VERIFICATION RULE:
1. Code Inspection Stage:
- Check the current implementation in the codebase
- Verify where changes need to be made
- Understand the component structure and dependencies
2. Implementation Stage:
- Make the necessary code changes
- Verify changes are in the correct files using grep or file inspection
- Run any necessary linting/type checks
3. Deployment Stage:
- For Docker deployments, which this repository is, run the following command to rebuild the frontend container:
* Rebuild the frontend container: `docker-compose up -d --build frontend`
* Check container logs for any errors
# Traefik Configuration Rule
IF You need to break this rule, explain clearly and exactly why and wait for a confirmation
## Purpose
This rule ensures consistent Traefik routing configuration across the ColourStream application by using container labels instead of external Traefik configurations.
## Procedure
1. Always use container labels in docker-compose.yml for Traefik routing:
- DO NOT use external Traefik configuration files (e.g., traefik.toml, traefik.yaml)
- DO USE DOCKER COMPOSE LABELS
- DO use service-level labels for all routing configuration
2. Required label structure for Traefik routing:
- Define router rules using `traefik.http.routers.[service-name].rule`
- Define entrypoints using `traefik.http.routers.[service-name].entrypoints`
- Define TLS configuration using `traefik.http.routers.[service-name].tls`
- Define middlewares using `traefik.http.routers.[service-name].middlewares`
- Define services using `traefik.http.services.[service-name].loadbalancer.server.port`
3. Example of correct implementation:
```yaml
services:
frontend:
# ... other configuration
labels:
- "traefik.enable=true"
- "traefik.http.routers.frontend.rule=Host(`app.colourstream.example.com`)"
- "traefik.http.routers.frontend.entrypoints=websecure"
- "traefik.http.routers.frontend.tls=true"
- "traefik.http.services.frontend.loadbalancer.server.port=3000"
```
4. When adding a new service:
- Always include appropriate traefik labels
- Ensure unique router and service names
- Document the routing configuration in service comments
5. When modifying existing services:
- Maintain the same label structure
- Update labels as needed for new routing requirements
- Test routing changes before deployment
## Benefits
- Centralized configuration in docker-compose.yml
- Easier maintenance and troubleshooting
- Consistent deployment across environments
- Better visibility of routing configuration
- Simplified CI/CD pipeline
# Casing and Naming Conventions Rule
## Purpose
This rule ensures consistent naming conventions across the ColourStream codebase, improving readability, maintainability, and reducing errors related to inconsistent casing.
## General Principles
- Be consistent within each file and across related files
- Choose meaningful, descriptive names that indicate purpose
- Avoid abbreviations unless they are widely understood
- Prioritize readability over brevity
## TypeScript/JavaScript Conventions
### Variables and Functions
- Use camelCase for variables, function names, method names, and instance properties
- Example: `getUserData`, `isAuthenticated`, `roomConfig`
- Use PascalCase for class names, interfaces, types, and React components
- Example: `UserProfile`, `AuthService`, `RoomConfig`
- Use UPPER_SNAKE_CASE for constants and environment variables
- Example: `MAX_RETRY_ATTEMPTS`, `API_BASE_URL`
### Files and Directories
- Use PascalCase for React component files
- Example: `AdminDashboard.tsx`, `ProtectedRoute.tsx`
- Use camelCase for utility and service files
- Example: `api.ts`, `websocket.ts`
- Use camelCase for directory names in the src folder
- Example: `components`, `utils`, `hooks`
### React Components
- Use PascalCase for component file names and the component itself
- Example: `UserProfile.tsx` contains `const UserProfile: React.FC = () => {...}`
- Use camelCase for custom hooks, starting with "use"
- Example: `useAuth`, `useRoomData`
## Database and Prisma Conventions
### Model Names
- Use mixed casing for model names in Prisma schema based on entity type:
- Use PascalCase for primary entities (e.g., `Room`, `WebAuthnCredential`)
- Use camelCase for configuration or settings entities (e.g., `obssettings`, `blockedIP`)
- Ensure consistency between Prisma model names and their usage in code
### Field Names
- Use camelCase for field names in database models
- Example: `userId`, `createdAt`, `streamKey`
- Use consistent naming patterns for related fields across models
## API Conventions
### Endpoints
- Use kebab-case for API endpoints
- Example: `/api/user-profile`, `/api/room-settings`
- Use RESTful naming conventions for CRUD operations
### Request/Response Objects
- Use PascalCase for interface/type names
- Example: `UserProfileResponse`, `RoomCreateRequest`
- Use camelCase for properties within these objects
- Example: `{ userId: string, displayName: string }`
## Implementation
1. When creating new code:
- Follow these conventions from the start
- Reference existing code with consistent naming
2. When modifying existing code:
- Match the existing style if it's consistent
- If inconsistent, consider refactoring for consistency
- Document any necessary deviations
3. When refactoring for consistency:
- Make focused changes in a dedicated PR
- Update all references to renamed entities
- Test thoroughly to ensure no regressions
## Exceptions
- External libraries or frameworks may require different conventions
- Legacy code may maintain its conventions until scheduled refactoring
- Document any exceptions in comments for clarity
{
"ruleName": "DockerComposeEnvVariableFormat",
"description": "Enforce DRY (Don't Repeat Yourself) principles in docker-compose environment variables",
"version": "1.0",
"rules": [
{
"id": "ENV-001",
"rule": "Use direct variable references without default values in docker-compose",
"description": "Always use direct variable references like 'VARIABLE: ${VARIABLE}' instead of 'VARIABLE: ${VARIABLE:-default}'. Default values should be defined in a central .env file to maintain DRY principles and simplify debugging. The ':-' syntax adds unnecessary complexity when diagnosing issues.",
"pattern": "\\${[A-Za-z0-9_]+:-[^}]+}",
"filePattern": "docker-compose.y*ml",
"severity": "warning",
"examples": {
"incorrect": "MINIO_DOMAIN: ${S3_DOMAIN:-s3.colourstream.johnrogerscolour.co.uk}",
"correct": "MINIO_DOMAIN: ${S3_DOMAIN}"
},
"fixInstructions": "1. Remove default values from docker-compose.yml\n2. Add these values to your .env file instead\n3. This maintains DRY principle and centralizes configuration"
}
]
}