-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy path.clinerules
239 lines (180 loc) · 8.99 KB
/
.clinerules
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
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
# Cline Rules
This file captures important patterns, preferences, and project intelligence that help me work more effectively with this project. It will evolve as I learn more about the project and your preferences.
## Project Overview
- This is a Next.js application with TypeScript that powers https://tfyp.org
- Primary functionality includes:
- Event Check-in Page
- Tree Identification and Tree ID quizzes
- Member management
- Member referral pages
- Custom forms/surveys
- Hidden/Deprecated Functionality:
- Tree Sponsorship/Thank-a-Tree
## Tech Stack
- Next.js 12.x
- React 17.x
- TypeScript
- Prisma ORM with MySQL database
- Material UI (MUI) 5.x
- Jest for testing
- ESLint and Prettier for code formatting
## Project Structure
- `/pages`: Next.js pages and API routes
- `/components`: React components organized by feature
- `/prisma`: Database schema and migrations
- `/utils`: Utility functions and helpers
- `/public`: Static assets
- `/test`: Test files
## Project Patterns
1. **Component Organization**: Components are organized by feature/domain in separate directories
2. **TypeScript Usage**: The project uses TypeScript for type safety
3. **Testing Approach**: Jest and React Testing Library for component testing
4. **Docker Development**: Development environment is containerized with Docker
## Implementation Paths
1. **Tree Functionality**: Components for tree display and identification are in the `components/tree` directory
2. **Event System**: Event-related components are in the `components/event` directory
3. **Maps Integration**: Map components are in the `components/maps` directory
4. **User Management**: User-related functionality is in the `components/account` directory
## Database Structure
The project uses Prisma with MySQL. Key database elements include:
- SQL views and triggers (based on SQL files in the prisma directory)
- Species data for trees
- Change log tracking
## Development Environment
1. **DevContainer Setup**:
- The project uses VSCode DevContainers for development
- Container rebuilds require special handling for persistent data
- The docker-compose.yml and rebuild-devcontainer.sh files have been configured to preserve Cline's Recent Tasks history across container rebuilds
2. **Database Initialization**: Database setup scripts are in the `.devcontainer` directory
3. **Permissions Handling**: There appears to be special handling for NPM permissions (NPM_PERMISSIONS_FIX.md)
4. **Container Persistence**:
- VSCode extensions data (including Cline data) is stored in a persistent volume called vscode-server
- GitHub CLI authentication data is stored in a persistent volume called github-cli-config
- The docker-compose.yml file includes these volumes mounted at:
- /home/node/.vscode-server (for VSCode extensions)
- /home/node/.config/gh (for GitHub CLI authentication)
- The rebuild-devcontainer.sh script preserves these volumes during rebuilds with grep -v filters
5. **Memory Bank Usage**:
- The `read-memory-bank.sh` script should be run at the start of each task
- This script reads all memory bank files in the recommended order
- It provides a comprehensive view of the project context
- Usage: `./read-memory-bank.sh` from the project root
6. **VSCode Configuration**:
- The project uses Prettier as the default formatter
- ESLint is configured to run on save with the "source.fixAll.eslint" code action
- Specific formatter settings are defined for JavaScript, TypeScript, and TypeScript React files
- The .prettierrc file defines formatting rules (140 character line length, 2 space indentation, etc.)
## Testing Patterns
1. **Component Mocking**: Mock components are in the `__mocks__` directory
2. **Test Organization**: Tests are organized by component/page in the `test` directory
3. **TypeScript Error Handling**: Do not correct TypeScript errors until the task is complete and ready for commit, especially when initially writing tests that may fail by design
4. **Test Implementation**: Never mock the component being tested
- Mock dependencies and external services, not the component under test
- Test the actual component implementation, not a mock version
## Development Workflow
1. **TypeScript Validation**: TypeScript errors should not be corrected during initial development or test writing
- Allow type errors to exist while developing functionality
- Only fix type errors when the task is complete and code is ready to commit
- This is particularly important when writing tests that may intentionally fail at first
## User Interface Patterns
1. **Material-UI**: The project uses Material-UI (MUI) 5.x components
2. **Rich Text Editing**: MUI-RTE for rich text editing
3. **Map Components**: Custom map components for location selection and display
## Development Guidelines
### Code Style
1. Follow TypeScript best practices:
- Use proper typing for all variables, parameters, and return values
- Avoid using `any` type when possible
- Use interfaces for object shapes
- Use type guards when necessary
2. React Component Guidelines:
- Use functional components with hooks
- Keep components focused on a single responsibility
- Extract reusable logic into custom hooks in `/utils/hooks`
- Use proper prop typing with TypeScript interfaces
3. State Management:
- Use React Query for server state
- Use React Context for global UI state when necessary
- Prefer local component state when possible
4. Styling:
- Use MUI components and styling system
- Follow the project's theme configuration in `/utils/theme.ts`
- Use emotion for custom styling when needed
### Database Operations
1. Always use Prisma client for database operations
2. Follow the schema defined in `/prisma/schema.prisma`
3. When creating migrations:
- Use `npx prisma migrate dev --name migration-name`
- Keep migrations focused on specific changes
- Document complex migrations
### API Development
1. Place API routes in `/pages/api`
2. Follow RESTful principles
3. Implement proper error handling and status codes
4. Use TypeScript interfaces for request and response types
## Git Workflow
1. For each new task or feature:
- Create a feature branch from main: `git checkout -b feature/descriptive-name`
- Use a naming convention like `feature/`, `bugfix/`, `hotfix/`, or `refactor/` prefix
2. Commit changes with meaningful messages:
- Use present tense ("Add feature" not "Added feature")
- Be descriptive but concise
- Reference issue numbers if applicable: "Add user profile page (#123)"
3. Before creating a PR:
- Ensure all tests pass: `npm test`
- Run linting: `npm run lint`
- Verify the feature works as expected
4. Create a Pull Request:
- Provide a clear title and description
- Reference any related issues
- Add appropriate reviewers
- Include screenshots for UI changes if applicable
5. After PR approval:
- Merge to main branch using `gh pr merge <PR-NUMBER> --merge --admin --delete-branch` to bypass branch protection rules
- Do not attempt to approve your own PRs (use `gh pr merge` directly without `gh pr review`)
- The feature branch will be automatically deleted when using the `--delete-branch` flag
## Common Tasks
### Adding a New Feature
1. Create a feature branch: `git checkout -b feature/descriptive-name`
2. Plan the feature and identify affected components
3. Update database schema if necessary
4. Create or modify API endpoints
5. Implement UI components
6. Add tests
7. Update documentation
8. Commit changes with meaningful messages
9. Create a pull request for review and merge
### Fixing Bugs
1. Create a bugfix branch: `git checkout -b bugfix/issue-description`
2. Reproduce the issue
3. Write a test that fails due to the bug
4. Fix the implementation
5. Verify the test passes
6. Document the fix
7. Commit changes with meaningful messages
8. Create a pull request for review and merge
### Database Schema Changes
1. Create a feature branch: `git checkout -b feature/db-schema-change-description`
2. Modify `/prisma/schema.prisma`
3. Generate a migration with `npx prisma migrate dev --name descriptive-name`
4. Update affected API routes and components
5. Test the changes thoroughly
6. Commit changes with meaningful messages
7. Create a pull request for review and merge
## Deployment
- The application is deployed to production at https://tfyp.org
- Node.js 14.x is required for deployment
- Heroku is used for hosting
## Local Development Setup
1. Install MySQL
2. Create a database named `treefolksyp`
3. Run `npm install`
4. Run `npx prisma generate`
5. Run `npx prisma migrate deploy`
6. Start the development server with `npm run server`
## Important Notes
- The codebase uses Node.js 14.x
- Some features like Tree Sponsorship are deprecated but still in the codebase
- The project follows ESLint and Prettier configurations defined in the root files
- The dev container configuration has been permanently modified to preserve Cline's Recent Tasks history across rebuilds
This file will be updated as I learn more about the project and your preferences.