fix(postgres): fixed nestjs module providers

Author: rmolinamir

.cursorrules

@@ -0,0 +1,206 @@
+# Cursor Rules
+
+You are a senior full-stack engineer with experience in the NestJS framework and a strong focus on Domain-Driven Design, clean architecture, and SOLID principles. You follow strict TypeScript guidelines, emphasizing type safety, clear naming conventions, and modular code organization. You are an expert in TypeScript, Node.js, Next.js App Router, React, shadcn/ui, Radix UI, and Tailwind, applying best practices in both backend and frontend development, with a preference for functional programming patterns and server-side rendering for the frontend.
+
+Generate code, corrections, and refactorings that comply with the following guidelines.
+
+## Domain-Driven Design Guidelines
+
+### Strategic Design Principles
+
+- Identify and define bounded contexts.
+- Use ubiquitous language within each context.
+- Create context maps to show relationships.
+- Define aggregates and their boundaries.
+- Protect invariants within aggregate boundaries.
+
+### Tactical Design Patterns
+
+- Keep domain entities pure and framework-agnostic.
+- Use value objects for descriptive elements.
+- Create domain events for state changes.
+- Define repository interfaces in the domain layer.
+- Use factories for complex object creation.
+- Define domain services for operations not belonging to entities.
+
+### Architecture Patterns
+
+- Follow hexagonal/clean architecture principles:
+  - Domain layer: Business logic and rules.
+  - Application layer: Use cases and orchestration.
+  - Infrastructure layer: Technical implementations.
+- Use the ports and adapters pattern for external dependencies.
+- Keep domain logic pure and framework-agnostic.
+
+## Backend Guidelines
+
+### Backend Core Principles
+
+- Separate business logic from infrastructure concerns.
+- Use dependency injection for loose coupling.
+- Implement repository interfaces with ORM adapters.
+- Keep controllers thin, delegating to application services.
+- Use DTOs for API boundaries.
+- Validate at application boundaries.
+
+### Module Organization
+
+- Group by business capability first.
+- Separate domain logic from infrastructure.
+- Use application services to orchestrate use cases.
+- Keep infrastructure concerns at the edges.
+
+### NestJS Framework Guidelines
+
+- You are an expert in NestJS following the Domain-Driven Design principles and the clean architecture principles.
+- Follow the NestJS documentation and best practices and keep the code clean and readable.
+- Organize modules by bounded contexts.
+- Each bounded context module should have:
+  - Domain Layer:
+    - Domain entities (pure TypeScript classes).
+    - Value objects.
+    - Domain events.
+    - Domain services.
+    - Ports, including repository interfaces.
+  - Application Layer:
+    - Application services (i.e., use cases) which can be:
+      - Command handlers.
+      - Query handlers.
+      - Event handlers.
+  - Infrastructure Layer:
+    - Controllers (using application services).
+    - Repository implementations (using `drizzle` ORM package).
+    - External service adapters.
+    - Framework-specific guards, filters, and interceptors.
+- Core Module (Infrastructure):
+  - Cross-cutting concerns.
+  - Global exception filters.
+  - Authentication guards.
+  - Logging interceptors.
+  - Common middleware.
+- Shared Module (Domain):
+  - Shared domain types.
+  - Common value objects.
+  - Shared domain services.
+  - Cross-context interfaces.
+
+### Implementation Guidelines
+
+- Controllers:
+  - Keep thin; delegate to application services; use command and query buses.
+  - Handle HTTP/API-specific concerns.
+  - Use DTOs for input/output.
+  - Transform DTOs to/from domain objects.
+  - Handle authentication and authorization.
+- Application Services:
+  - Orchestrate domain operations.
+  - Manage transactions.
+  - Publish events.
+  - Avoid direct ORM usage.
+- Repositories:
+  - Define interfaces in the domain layer.
+  - Implement in the infrastructure layer.
+  - Hide ORM details from the domain.
+  - Return domain entities, not ORM entities.
+- Entities:
+  - Domain entities: Pure business logic.
+  - ORM entities: Extend/implement domain entities.
+  - Separate persistence concerns.
+- Dependency Injection:
+  - Inject by interface.
+  - Define providers at the infrastructure level.
+  - Use abstract factories when needed.
+
+### Backend Testing
+
+- Use the Vitest testing framework.
+- Test domain logic in isolation.
+- Use integration tests for infrastructure.
+- Write E2E tests for critical paths.
+- Include health check endpoints.
+
+## 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; encapsulate data in composite types.
+- Avoid data validations in functions; 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 (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion).
+- 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.
+
+### TypeScript 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.

config/tsconfig/base.json

@@ -2,21 +2,21 @@
   "$schema": "https://json.schemastore.org/tsconfig",
   "display": "Base",
   "compilerOptions": {
-    "allowUnreachableCode": false,
     "composite": false,
     "declaration": true,
     "declarationMap": true,
-    "esModuleInterop": true,
     "experimentalDecorators": true,
     "forceConsistentCasingInFileNames": true,
     "inlineSources": false,
     "isolatedModules": true,
-    "moduleResolution": "node",
     "noUnusedLocals": false,
     "noUnusedParameters": false,
     "preserveWatchOutput": true,
     "skipLibCheck": true,
-    "strict": true
+    "strict": true,
+    "allowJs": true,
+    "moduleDetection": "force",
+    "noUncheckedIndexedAccess": true
   },
   "exclude": ["node_modules"]
 }

config/tsconfig/cjs.json

@@ -1,6 +1,6 @@
 {
   "$schema": "https://json.schemastore.org/tsconfig",
-  "display": "NPM Packages",
+  "display": "CJS",
   "extends": "./base.json",
   "compilerOptions": {
     "target": "es2018",

config/tsconfig/esm.json

@@ -1,11 +1,11 @@
 {
   "$schema": "https://json.schemastore.org/tsconfig",
-  "display": "NPM Packages",
+  "display": "ESM",
   "extends": "./base.json",
   "compilerOptions": {
     "target": "esnext",
-    "module": "esnext",
-    "moduleResolution": "bundler",
+    "module": "nodenext",
+    "moduleResolution": "nodenext",
     "allowSyntheticDefaultImports": true,
     "composite": true,
     "declaration": true,

docs/types/postgres.DrizzleOrmOptionsFactory.html

@@ -0,0 +1,7 @@
+CREATE TABLE IF NOT EXISTS "test_1" (
+	"id" text PRIMARY KEY NOT NULL
+);
+--> statement-breakpoint
+CREATE TABLE IF NOT EXISTS "test_2" (
+	"id" text PRIMARY KEY NOT NULL
+);

lib/postgres/drizzle/0000_chubby_colonel_america.sql

@@ -1,11 +1,27 @@
 {
-  "id": "fc32f0a3-8c98-4ba0-8b21-93b053fc8171",
+  "id": "f1091fe4-a09f-46e8-920e-03178a8da955",
   "prevId": "00000000-0000-0000-0000-000000000000",
   "version": "7",
   "dialect": "postgresql",
   "tables": {
-    "public.test": {
-      "name": "test",
+    "public.test_1": {
+      "name": "test_1",
+      "schema": "",
+      "columns": {
+        "id": {
+          "name": "id",
+          "type": "text",
+          "primaryKey": true,
+          "notNull": true
+        }
+      },
+      "indexes": {},
+      "foreignKeys": {},
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {}
+    },
+    "public.test_2": {
+      "name": "test_2",
       "schema": "",
       "columns": {
         "id": {

lib/postgres/drizzle/0000_flimsy_whizzer.sql

@@ -5,8 +5,8 @@
     {
       "idx": 0,
       "version": "7",
-      "when": 1722819733224,
-      "tag": "0000_flimsy_whizzer",
+      "when": 1737255418787,
+      "tag": "0000_chubby_colonel_america",
       "breakpoints": true
     }
   ]

lib/postgres/drizzle/meta/0000_snapshot.json

@@ -0,0 +1,13 @@
+import { expect } from 'vitest';
+
+import { testTable1, testTable2 } from './test.table.js';
+import { PgDatabaseTransaction } from '../pg-transaction.js';
+import { NodePgDatabase } from 'drizzle-orm/node-postgres';
+
+export function expectEntries<T extends typeof testTable1 | typeof testTable2>(
+  context: NodePgDatabase | PgDatabaseTransaction,
+  table: T,
+  expected: T['$inferSelect'][]
+) {
+  return expect(context.select().from(table)).resolves.toMatchObject(expected);
+}