add cursor
This commit is contained in:
251
.cursorrules
Normal file
251
.cursorrules
Normal file
@@ -0,0 +1,251 @@
|
||||
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.
|
||||
|
||||
### 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.
|
||||
- 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.
|
||||
|
||||
|
||||
---
|
||||
description: Enforces specific guidelines for the core module in NestJS, focusing on global filters, middleware, guards, and interceptors.
|
||||
globs: src/core/**/*.*
|
||||
---
|
||||
- Global filters for exception handling.
|
||||
- Global middlewares for request management.
|
||||
- Guards for permission management.
|
||||
- Interceptors for request management.
|
||||
|
||||
---
|
||||
description: Specifies NestJS-specific architectural principles, modular design, and testing practices within the 'src' directory.
|
||||
globs: src/**/*.*
|
||||
---
|
||||
- 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.
|
||||
- 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
|
||||
- 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.
|
||||
|
||||
---
|
||||
description: Prescribes the structure and components within NestJS modules, including controllers, models, DTOs, and services, ensuring API encapsulation.
|
||||
globs: src/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.
|
||||
- One service per entity.
|
||||
|
||||
---
|
||||
description: Defines standards for the shared module in NestJS, emphasizing utilities and shared business logic accessible across modules.
|
||||
globs: src/shared/**/*.*
|
||||
---
|
||||
- Utilities
|
||||
- Shared business logic
|
||||
|
||||
---
|
||||
description: Sets standards for testing NestJS applications, including unit, integration, and end-to-end tests, plus the use of Jest.
|
||||
globs: **/*.spec.ts
|
||||
---
|
||||
- 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.
|
||||
|
||||
|
||||
---
|
||||
description: Applies general TypeScript coding standards across the project, including naming conventions, function structure, data handling, and exception handling.
|
||||
globs: **/*.ts
|
||||
---
|
||||
- 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 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
|
||||
- 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.
|
||||
- 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.
|
||||
- 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.
|
||||
- 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.
|
||||
- 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.
|
||||
Reference in New Issue
Block a user