78 lines
3.6 KiB
Plaintext
78 lines
3.6 KiB
Plaintext
You are an expert in Typescript and Node.js. You are building a web server in opponiated framework.
|
|
|
|
Tool usage
|
|
- When in doubt - use web tool to get answers from the web.
|
|
- Search web when you have some failures.
|
|
|
|
Code Style and Structure
|
|
- Write concise, technical TypeScript code with accurate examples.
|
|
- Use functional and declarative programming patterns; avoid classes.
|
|
- Prefer iteration and modularization over code duplication.
|
|
- Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError).
|
|
- All sources must be imported using "@/" prefix. `import "@/utils/log"` means `import "/sources/utils/log.ts"`.
|
|
- Always use absolute imports.
|
|
|
|
Folder structure
|
|
- Root of the sources is "/sources"
|
|
- Non-application logic files are in "/sources/modules"
|
|
- Low level or too abstract utilities are in "/sources/utils"
|
|
- Recipes, ie scripts that you want to run outside of the server are in "/sources/recipes"
|
|
- Applications are in /sources/apps
|
|
- API server is in /sources/apps/api with routes in /sources/apps/api/routes
|
|
- Modules are in /sources/modules
|
|
|
|
Naming Conventions
|
|
- Use lowercase with dashes for directories (e.g., components/auth-wizard).
|
|
|
|
TypeScript Usage
|
|
- Use TypeScript for all code; prefer interfaces over types.
|
|
- Avoid enums; use maps instead.
|
|
- Use functional components with TypeScript interfaces.
|
|
- Use strict mode in TypeScript for better type safety.
|
|
|
|
Tests
|
|
- Write tests using Vitest.
|
|
- Always name test files in the same way as the source file, but with ".spec.ts" suffix.
|
|
|
|
Utilities
|
|
- When writing utility function always name file and function in the same way, so it is easy to find it.
|
|
- Utility functions should be modular and not too complex.
|
|
- When writing utility functions, always write tests for them BEFORE writing the code.
|
|
- Iterate your implementation and tests until you are sure that the function works as expected.
|
|
- When writing utility functions, always write documentation for them.
|
|
|
|
Modules
|
|
- Modules are bigger than utility functions and their goal is to abstract away complexity
|
|
- Each module should have dedicated directory.
|
|
- Modules usually don't have application specific logic, they are more general and could be copied to other projects.
|
|
- Modules can depend on other modules, but should not depend on application specific logic.
|
|
- Prefer to write code as modules instead of application specific code.
|
|
- When using a module is a good idea:
|
|
- When you need to integrate with external services
|
|
- When you need to abstract away complexity of some library
|
|
- When you want to implement some group of functions that are related to each other, like math, date, etc.
|
|
- Some known modules are:
|
|
- ai: AI wrappers to interact with AI services
|
|
- eventbus: event bus to send and receive events between modules and applications
|
|
- lock: simple lock to synchronize access to resources in the whole cluster
|
|
- media: tools to work with media files
|
|
|
|
Applications
|
|
- Applications has some application specific logic
|
|
- Applications have the most of the complexity and other parts of the code should assist by reducing complexity here.
|
|
- When using prompts, write them to "_prompts.ts" file relative to the application.
|
|
|
|
Database
|
|
- Prisma is used as ORM.
|
|
- Use "inTx" to wrap database operations in transactions.
|
|
- Do not update schema without absolute necessity.
|
|
- For complex fields, use "Json" type.
|
|
|
|
Events
|
|
- eventbus allows to send and receive events inside of the process and between different processes.
|
|
- eventbus is local or redis based.
|
|
- use "afterTx" to send events after transaction is committed successfully instead of directly emitting events.
|
|
|
|
Libraries
|
|
- Always use Zod for validation of inputs.
|
|
- Always use axios for HTTP requests. |