yindo/posthog
1
0
Fork 0
mirror of https://github.com/BillyOutlast/posthog.git synced 2026-02-04 03:01:23 +01:00
Code Issues Packages Projects Releases Wiki Activity

chore: change claude rules (#35443)

Browse Source
This commit is contained in:
Paul D'Ambra
2025-07-22 16:16:06 +01:00
committed by GitHub
parent 05c9574a88
commit d5752d24c5
1 changed files with 13 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
CLAUDE.md
View File

@@ -4,14 +4,14 @@
- Tests:
- All tests: `pytest`
- Single test: `pytest path/to/test.py::TestClass::test_method`
- Frontend: `cd frontend && pnpm test`
- Single frontend test: `cd frontend && pnpm jest <test_file>`
- Frontend: `pnpm --filter=@poshog/frontend test`
- Single frontend test: `pnpm --filter=@poshog/frontend test <test_file>`
- Lint:
- Python: `ruff .`
- Frontend: `cd frontend && pnpm format`
- TypeScript check: `cd frontend && pnpm typescript:check`
- Frontend: `pnpm --filter=@poshog/frontend format`
- TypeScript check: `pnpm --filter=@poshog/frontend typescript:check`
- Build:
- Frontend: `cd frontend && pnpm build`
- Frontend: `pnpm --filter=@poshog/frontend build`
- Start dev: `./bin/start`
## Code Style
@@ -19,7 +19,13 @@
- Frontend: TypeScript required, explicit return types
- Imports: Use simple-import-sort, avoid direct dayjs imports (use lib/dayjs)
- Components: Use Lemon components (LemonButton, LemonInput, etc.) not antd
- CSS: Use utility classes instead of inline styles
- CSS: Use tailwind utility classes instead of inline styles
- Error handling: Prefer explicit error handling with typed errors
- Naming: Use descriptive names, camelCase for JS/TS, snake_case for Python
- Comments: Leave comments to explain tricky areas of the code or to explain WHY something is there, but don't just leave comments everywhere, the code should be default readable
- Comments: Leave comments to explain tricky areas of the code or to explain WHY something is there, but don't just leave comments everywhere, the code should be default readable
- Comments: should not duplicate the code below, don't tell me "this finds the shortest username" tell me _why_ that is important, if it isn't important don't add a comment
- Python tests: do not need doc comments, give them good names, and leave off with the comments
- jest tests: when writing jest tests, prefer a single top-level describe block in a file
- any tests: prefer to use parameterized tests, think carefully about what input and output look like so that the tests exercise the system and explain the code to the future traveller
- parameterized tests: in python use the parameterized library for parameterized tests
- always remember that there is a tension between having the fewest parts to code (a simple system) and having the most understandable code (a maintainable system). structure code to balance these two things.