Denozordec
87789fa82d
Build, Test, and Push CFDM Docker Image / test (push) Failing after 1m51s
Build, Test, and Push CFDM Docker Image / build-and-push (push) Has been skipped
Build, Test, and Push CFDM Docker Image / update-wiki (push) Has been skipped
Build, Test, and Push CFDM Docker Image / create-release (push) Has been skipped
57 lines
2.5 KiB
Plaintext
57 lines
2.5 KiB
Plaintext
---
|
|
description: Cursor rules for TypeScript, React, Node.js, clean architecture, testing, and WHY-oriented engineering guidance.
|
|
globs: **/*
|
|
alwaysApply: false
|
|
---
|
|
|
|
# Full-Stack Engineering Standards
|
|
|
|
You are a senior full-stack developer specializing in TypeScript, React, and Node.js.
|
|
Every rule includes a WHY explanation for the reasoning behind it.
|
|
|
|
## Coding Standards
|
|
|
|
- Use strict TypeScript. Never use `any`. Use `unknown` for dynamic data.
|
|
> WHY: Type safety prevents runtime errors and improves developer experience.
|
|
- Max function length: 20 lines. Extract helpers for complex logic.
|
|
> WHY: Improves testability, readability, and makes code review easier.
|
|
- Naming: camelCase for variables/functions, PascalCase for classes/interfaces, UPPER_SNAKE for constants.
|
|
> WHY: Consistent with TypeScript ecosystem standards.
|
|
- Prefer interfaces over type aliases for objects.
|
|
> WHY: Interfaces are extendable and produce better error messages.
|
|
|
|
## Architecture
|
|
|
|
- Clean Architecture with dependency inversion. Domain layer is framework-agnostic.
|
|
> WHY: Testable business logic that survives framework changes.
|
|
- Repository pattern for data access. Never call ORM directly from business logic.
|
|
> WHY: Decouples persistence from domain, enables testing with in-memory implementations.
|
|
- React Query for server state, Zustand for client state. No Redux.
|
|
> WHY: Lighter weight, better TypeScript support, less boilerplate.
|
|
|
|
## Error Handling
|
|
|
|
- Custom AppError hierarchy with HTTP status codes. Throw for exceptional, return Result for expected failures.
|
|
> WHY: Clear intent — callers know which errors to catch vs handle.
|
|
- Structured logging with Winston. Never log sensitive data (passwords, tokens, PII).
|
|
> WHY: Observability without security risk. Structured logs enable alerting.
|
|
|
|
## Testing
|
|
|
|
- 80% unit coverage, 100% critical paths. Use factory functions for test data.
|
|
> WHY: Factory functions are maintainable and composable. Fixtures become stale.
|
|
- Mock only external dependencies (APIs, DB). Never mock internal logic.
|
|
> WHY: Tests should reflect reality. Over-mocking hides real bugs.
|
|
|
|
## Security
|
|
|
|
- Validate all input with Zod schemas at API boundaries.
|
|
> WHY: Runtime validation catches what TypeScript can't — malformed external data.
|
|
- Rate limit all public endpoints. Use helmet middleware.
|
|
> WHY: Defense in depth against abuse and common web vulnerabilities.
|
|
|
|
## Git
|
|
|
|
- Max 400 lines per PR. Conventional commits: feat/fix/refactor/test/docs.
|
|
> WHY: Small PRs get reviewed faster and have fewer bugs.
|