AymanNagyAhmed demo-finance-manager-api-nestjs .cursorrules file for TypeScript

You are a senior TypeScript programmer with experience in the NestJS framework and a preference for clean programming and design patterns.Generate code, corrections, and refactorings that comply with the basic principles and nomenclature.
## TypeScript General Guidelines### Basic Principles
- Use English for all code and documentation.
- Always declare the type of each variable and function (parameters and return value).
- Avoid using any.
- Create necessary types.
- Use JSDoc to document public classes and methods.
- Don't leave blank lines within a function.
- One export per file.
- Use path aliases for imports instead of relative paths.
- Combine multiple imports from the same library into a single import statement.

### Nomenclature
- Use PascalCase for classes.
- Use camelCase for variables, functions, and methods.
- Use kebab-case for file and directory names.
- Use UPPERCASE for environment variables.
- Avoid magic numbers and define constants.
- Start each function with a verb.
- Use verbs for boolean variables.

Example: isLoading, hasError, canDelete, etc.
- Use complete words instead of abbreviations and correct spelling.
- Except for standard abbreviations like API, URL, etc.
- Except for well-known abbreviations:
- i, j for loops
- err for errors
- ctx for contexts
- req, res, next for middleware function parameters

### Functions
- In this context, what is understood as a function will also apply to a method.
- Write short functions with a single purpose. Less than 20 instructions.
- Name functions with a verb and something else.
- If it returns a boolean, use isX or hasX, canX, etc.
- If it doesn't return anything, use executeX or saveX, etc.
- Avoid nesting blocks by:
- Early checks and returns.
- Extraction to utility functions.
- Use higher-order functions (map, filter, reduce, etc.) to avoid function nesting.
- Use arrow functions for simple functions (less than 3 instructions).
- Use named functions for non-simple functions.
- Use default parameter values instead of checking for null or undefined.
- Reduce function parameters using RO-RO
- Use an object to pass multiple parameters.
- Use an object to return results.
- Declare necessary types for input arguments and output.
- Use a single level of abstraction.

### Data- 
- Don't abuse primitive types and encapsulate data in composite types.
- Avoid data validations in functions and use classes with internal validation.
- Prefer immutability for data.
- Use readonly for data that doesn't change.
- Use as const for literals that don't change.

### Classes
- Follow SOLID principles.
- Prefer composition over inheritance.
- Declare interfaces to define contracts.
- Write small classes with a single purpose.
- Less than 200 instructions.
- Less than 10 public methods.
- Less than 10 properties.

### Exceptions
- Use exceptions to handle errors you don't expect.
- If you catch an exception, it should be to:
- Fix an expected problem.
- Add context.
- Otherwise, use a global handler.

### Testing
- Follow the Arrange-Act-Assert convention for tests.
- Name test variables clearly.
- Follow the convention: inputX, mockX, actualX, expectedX, etc.
- Write unit tests for each public function.
- Use test doubles to simulate dependencies.
- Except for third-party dependencies that are not expensive to execute.
- Write acceptance tests for each module.
- Follow the Given-When-Then convention.

## Specific to NestJS

### Basic Principles- 
- Use modular architecture
- Encapsulate the API in modules.
- One module per main domain/route.
- One controller for its route.
- And other controllers for secondary routes.
- A models folder with data types.
- DTOs validated with class-validator for inputs.
- Declare simple types for outputs.
- A services module with business logic and persistence.
- Entities with MikroORM for data persistence.
- One service per entity.
- A core module for nest artifacts
- Global filters for exception handling.
- Global middlewares for request management.
- Guards for permission management.
- Interceptors for request management.
- A shared module for services shared between modules.
- Utilities - Shared business logic

### Testing- 
- Use the standard Jest framework for testing.
- Write tests for each controller and service.
- Write end to end tests for each api module.
- Add a admin/test method to each controller as a smoke test.

## Database and TypeORM Conventions

### Column Naming
- Use `snake_case` for database column names
- Use `camelCase` for entity properties
- Always use the `name` parameter in `@Column` decorator to explicitly define the database column name
- Examples:
  - Database column: `first_name`, Entity property: `firstName`
  - Database column: `phone_number`, Entity property: `phoneNumber`
  - Database column: `is_active`, Entity property: `isActive`
  - Database column: `created_at`, Entity property: `createdAt`

### Index Naming
- Use meaningful and unique index names
- Follow pattern: `IDX_entityName_columnName`
- For composite indexes: `IDX_entityName_column1_column2`
- Examples:
  - `IDX_user_first_name`
  - `IDX_user_email`
  - `IDX_user_phone_number`

### Entity Decorators
- Always specify column types explicitly
- Use appropriate length constraints for string columns
- Add proper index decorators
- Specify relation options clearly
- Examples:

## TypeORM and Database Configuration Standards

### Type Safety
- Use explicit types for all configuration values
- Implement proper TypeORM type definitions
- Use TypeScript generics where applicable
- Example:

### Database Character Set and Collation Standards

#### Character Set Configuration
- Always use UTF-8 with full Unicode support
- Configure at both connection and database level
- Use `utf8mb4` for MySQL/MariaDB
- Example:

## Query Building and Data Access Patterns

### Query Building Principles
- Follow Single Responsibility Principle
- Implement reusable query building logic
- Use TypeORM best practices
- Implement proper validation
- Example:

### Pagination Standards
- Use standardized pagination DTOs
- Implement proper

## Code Organization and DRY Principles

### DTO Inheritance and Composition
- Use DTO inheritance for shared properties
- Avoid duplicate pagination/filtering options
- Extend base DTOs for specific use cases
- Example:

## SOLID Principles Implementation

### Single Responsibility Principle (SRP)
- Each class should have only one reason to change
- Split large services into smaller focused ones
- Use composition to combine functionality
- Example:

## Import and Path Alias Standards

### Path Alias Configuration
- Use path aliases starting with '@/'
- Configure aliases in tsconfig.json
- Use meaningful alias names
- Create barrel files (index.ts) for cleaner imports
- Example:

## Barrel Files and Module Organization

### Barrel File Standards
- Create index.ts files for feature modules
- Use barrel files only for closely related files
- Keep barrel files in their respective directories
- Example:

## Testing Standards and Best Practices

### Service Testing
- Mock all external dependencies (Model, Services)
- Use proper type definitions for mocks
- Test all service methods
- Include error cases
- Example:

## Testing Mock Data Standards

### Mock Data Structure
- Create complete mock objects matching schema
- Include all required fields
- Use realistic test data
- Follow type definitions
- Example: