@edifice.io/edifice-nestjs-core 1.0.0-develop-pedago.7 → 1.0.0-develop-pedago.20251210153355

package/README.md

@@ -34,20 +34,24 @@ It registers your application with the Edifice App Registry at startup.
 This process scans all controllers for `@RequirePermission` decorators, collects all declared workflow permissions, and sends them to the registry along with application metadata.
 
 **How it works:**
+
 - On application bootstrap, `AppRegistryService.registerApp()` is called.
 - It extracts all permissions from your controllers using reflection.
 - It sends an `AppRegistrationRequestDTO` to the registry via NATS.
 - The registration is retried every 10 seconds until successful.
 
 **Where and when:**
+
 - Registration happens automatically during the bootstrap phase (see `createApp()` in `bootstrap.utils.ts`).
 - You do not need to call it manually; it is triggered by the core module (`CoreModule`).
 
 **Why:**
+
 - This ensures your app and its permissions are discoverable and manageable by the Edifice platform.
 - It enables centralized permission management and workflow integration.
 
 **Example:**
+
 ```typescript
 import { CoreModule } from '@edifice.io/edifice-nestjs-core';
 
@@ -72,24 +76,29 @@ The `ConfigModule` is automatically included when you import `CoreModule` in you
 It provides centralized configuration management for your Edifice backend, using NestJS's `ConfigModule` and supporting environment variables.
 
 **Features:**
+
 - Loads configuration from environment variables.
 - Exposes configuration via NestJS `ConfigService` for dependency injection.
 - Provides helpers for logging, database, Swagger, and other modules to read their settings.
 
 **How it works:**
+
 - On application startup, the configuration is loaded from environment variables and injected globally.
 - All modules (database, logger, NATS, etc.) read their settings from `ConfigService`.
 - You can override configuration by setting environment variables.
 
 **Where and when:**
+
 - The configuration system is initialized automatically at application startup by `CoreModule`.
 - No manual setup is needed; just set the required environment variables.
 
 **Configuration:**
+
 - Set your main configuration using environment variables.
 - See [`src/config/EnvVars.md`](src/config/EnvVars.md) for a full list of supported variables and their defaults.
 
 **Example environment variables:**
+
 ```env
 APP_NAME=my-edifice-app
 APP_DISPLAY_NAME=My Edifice App
@@ -120,6 +129,7 @@ RSS_MEMORY=300
 ```
 
 **Example:**
+
 ```typescript
 import { Module } from '@nestjs/common';
 import { CoreModule } from '@edifice.io/edifice-nestjs-core';
@@ -140,16 +150,43 @@ export class AppModule {
 You do not need to configure the configuration system manually; it is ready to use when you import `CoreModule`.  
 All modules and services can access configuration via dependency injection of `ConfigService`.
 
+**Additional configuration:**
+
+You can also provide additional configuration like so
+
+```typescript
+import { Module } from '@nestjs/common';
+import { configuration as CoreConfig } from '@edifice.io/edifice-nestjs-core';
+import AppConfig from './config/configuration'; // Your app's configuration object
+import { CoreModule } from '@edifice.io/edifice-nestjs-core';
+import { ConfigModule } from '@nestjs/config';
+
+@Module({
+  imports: [
+    CoreModule,
+    // Use config defined in core + app config
+    // (warn: does not override core config fields)
+    ConfigModule.forRoot({
+      isGlobal: true,
+      load: [CoreConfig, AppConfig],
+    }),
+  ],
+})
+export class AppModule {}
+```
+
 #### Database (MikroORM Integration)
 
 The `DatabaseModule` provides seamless integration with MikroORM and PostgreSQL for your Edifice backend application.
 
 **Features:**
+
 - Automatic database connection and configuration using NestJS `ConfigModule`.
 - Runs pending migrations automatically at startup (if enabled in configuration).
 - Provides helpers to execute SQL scripts and manage schema evolution.
 
 **How to use:**
+
 - Import `DatabaseModule` in your main application module (already included in `CoreModule`).
 - Configure your database connection via environment variables (`DATABASE_URL`, `DATABASE_USER`, etc.).
 - Place your migration scripts in the `sql/` directory, following the naming convention:
@@ -158,9 +195,11 @@ The `DatabaseModule` provides seamless integration with MikroORM and PostgreSQL
 - Implement migration classes in `./src/migrations/`, each using the helper to execute the corresponding SQL files.
 
 **Example:**
+
 - Implement migration classes in `./src/migrations/`, each using the helper to execute the corresponding SQL files.
 
-*SQL migration script (`sql/01-init.sql`):*
+_SQL migration script (`sql/01-init.sql`):_
+
 ```sql
 -- Create a demo table
 CREATE TABLE demo_table (
@@ -169,13 +208,15 @@ CREATE TABLE demo_table (
 );
 ```
 
-*SQL rollback script (`sql/01-rollback.sql`):*
+_SQL rollback script (`sql/01-rollback.sql`):_
+
 ```sql
 -- Drop the demo table
 DROP TABLE IF EXISTS demo_table;
 ```
 
-*Migration class (`src/migrations/Migration01.ts`):*
+_Migration class (`src/migrations/Migration01.ts`):_
+
 ```typescript
 import { Migration } from '@mikro-orm/migrations';
 import { executeScript } from '@edifice.io/edifice-nestjs-core';
@@ -191,7 +232,8 @@ export class Migration01 extends Migration {
 }
 ```
 
-*Entity definition (`src/entities/demo.entity.ts`):*
+_Entity definition (`src/entities/demo.entity.ts`):_
+
 ```typescript
 import { Entity, PrimaryKey, Property } from '@mikro-orm/core';
 
@@ -205,7 +247,8 @@ export class Demo {
 }
 ```
 
-*Service using EntityRepository (`src/demo/demo.service.ts`):*
+_Service using EntityRepository (`src/demo/demo.service.ts`):_
+
 ```typescript
 import { Injectable } from '@nestjs/common';
 import { InjectRepository } from '@mikro-orm/nestjs';
@@ -231,7 +274,8 @@ export class DemoService {
 }
 ```
 
-*Demo module (`src/demo/demo.module.ts`):*
+_Demo module (`src/demo/demo.module.ts`):_
+
 ```typescript
 import { Module } from '@nestjs/common';
 import { CoreModule } from '@edifice.io/edifice-nestjs-core';
@@ -240,17 +284,15 @@ import { Demo } from '../entities/demo.entity';
 import { MikroOrmModule } from '@mikro-orm/nestjs';
 
 @Module({
-  imports: [
-    CoreModule,
-    MikroOrmModule.forFeature([Demo]),
-  ],
+  imports: [CoreModule, MikroOrmModule.forFeature([Demo])],
   providers: [DemoService],
   exports: [DemoService],
 })
 export class DemoModule {}
 ```
 
-**Note:**  
+**Note:**
+
 - Database connection parameters and migration behavior are controlled via environment variables.
 - The module ensures your database schema is up-to-date and provides utilities for advanced migration workflows.
 
@@ -259,17 +301,20 @@ export class DemoModule {}
 The `EventModule` provides services for tracking and recording user events (such as access and creation) in your Edifice backend application.
 
 **Features:**
+
 - Publishes user events (ACCESS, CREATE) to the Edifice event system via NATS.
 - Automatically extracts user/session information from requests.
 - Skips access events for mobile webview requests.
 - Centralizes event logging for analytics and auditing.
 
 **How to use:**
+
 - Import `CoreModule` in your main application module (already includes `EventModule`).
 - Inject `EventService` into your controllers or services.
 - Call `createAccessEvent(request, resourceType)` or `createCreateEvent(request, resourceType)` to record events.
 
 **Example:**
+
 ```typescript
 import { Controller, Get, Post, Req, Injectable } from '@nestjs/common';
 import { EventService, CoreModule } from '@edifice.io/edifice-nestjs-core';
@@ -297,10 +342,12 @@ export class ResourceController {
 ```
 
 **Configuration:**
+
 - The module uses `ConfigService` to get the application name (`app.name`).
 - Events are sent via the NATS client (`EntNatsServiceClient`), which is configured automatically by the core module.
 
-**Note:**  
+**Note:**
+
 - You do not need to configure the event system manually; it is ready to use when you import `CoreModule`.
 - Events are useful for analytics, auditing, and workflow triggers.
 
@@ -310,21 +357,25 @@ The `HealthModule` is automatically included when you import `CoreModule` in you
 It provides endpoints and services for readiness and liveness checks, integrating with NestJS Terminus.
 
 **Features:**
+
 - Exposes a `/health` endpoint for readiness and liveness checks.
 - Checks database connectivity (MikroORM), memory usage, and NATS connection.
 - Customizable thresholds for memory usage via configuration.
 - Integrates with monitoring and orchestration systems (Kubernetes, Docker, etc.).
 
 **How it works:**
+
 - The `HealthController` aggregates checks for database, memory, and NATS.
 - Health indicators are injected and run automatically.
 - The `/health` endpoint is public and can be used for probes.
 
 **Where and when:**
+
 - The health system is initialized automatically at application startup by `CoreModule`.
 - No manual configuration is needed; all dependencies are wired by the core module.
 
 **Configuration:**
+
 - Memory thresholds and other health parameters are set using environment variables:
   ```env
   HEAP_MEMORY=300
@@ -333,6 +384,7 @@ It provides endpoints and services for readiness and liveness checks, integratin
 - You can adjust these values to fit your deployment requirements.
 
 **Example:**
+
 ```typescript
 import { Module } from '@nestjs/common';
 import { CoreModule } from '@edifice.io/edifice-nestjs-core';
@@ -353,6 +405,7 @@ The `I18nModule` is automatically included when you import `CoreModule` in your
 It provides services for registering and fetching translations, enabling multi-language support for your Edifice backend.
 
 **Features:**
+
 - Registers translation files for your application at startup.
 - Fetches translations dynamically based on request headers (language detection).
 - Integrates with the Edifice ENT client for centralized translation management.
@@ -360,20 +413,24 @@ It provides services for registering and fetching translations, enabling multi-l
 - Used by other modules such as notifications to provide localized content.
 
 **How it works:**
+
 - The `I18nService` is initialized and injected by the core module.
 - On application startup, translation files in `assets/i18n/` are registered automatically.
 - You can fetch translations for the current request or application using provided service methods.
 - The notification system (`TimelineService` and custom notification services) uses `I18nService` to localize notification content.
 
 **Where and when:**
+
 - The i18n system is initialized automatically at application startup by `CoreModule`.
 - No manual configuration is needed; all dependencies are wired by the core module.
 
 **Configuration:**
+
 - The application name (`APP_NAME`) must be set using environment variables.
 - Place your translation files in the `assets/i18n/` directory (e.g., `fr.json`, `en.json`).
 
 **Example:**
+
 ```typescript
 import { Module, Controller, Get, Req } from '@nestjs/common';
 import { CoreModule, I18nService } from '@edifice.io/edifice-nestjs-core';
@@ -389,7 +446,9 @@ export class MyService {
   constructor(private readonly i18nService: I18nService) {}
 
   async getTranslations(@Req() request: FastifyRequest) {
-    return await this.i18nService.fetchCurrentAppTranslationsForRequest(request);
+    return await this.i18nService.fetchCurrentAppTranslationsForRequest(
+      request,
+    );
   }
 }
 ```
@@ -404,21 +463,25 @@ The `LoggerModule` is automatically included when you import `CoreModule` in you
 It provides structured logging using Pino, including access logs and request logs for your Edifice backend.
 
 **Features:**
+
 - Structured JSON logging for all requests and application events.
 - Request-scoped logger (`RequestLogger`) for contextual logs (user, path, method).
 - Access logger (`AccessLogger`) for logging authentication and access events.
 - Integrates with NestJS and supports log levels, child loggers, and custom fields.
 
 **How it works:**
+
 - The logger is initialized and injected by the core module.
 - You can inject `RequestLogger` or `AccessLogger` into your controllers, services, or middleware.
 - Logs are automatically enriched with request/session/user information.
 
 **Where and when:**
+
 - Logging is initialized automatically at application startup by `CoreModule`.
 - No manual configuration is needed; all dependencies are wired by the core module.
 
 **Configuration:**
+
 - Log level and options are set using environment variables:
   ```env
   LOG_LEVEL=info
@@ -427,9 +490,10 @@ It provides structured logging using Pino, including access logs and request log
 - You can adjust these values to fit your deployment requirements.
 
 **Example:**
+
 ```typescript
 import { Module, Controller, Get, Req } from '@nestjs/common';
-import { Logger } from "nestjs-pino";
+import { Logger } from 'nestjs-pino';
 import { CoreModule } from '@edifice.io/edifice-nestjs-core';
 import { FastifyRequest } from 'fastify';
 
@@ -444,7 +508,7 @@ export class MyController {
 
   @Get('hello')
   async hello(@Req() request: FastifyRequest) {
-    this.logger.info('Hello endpoint accessed', { path: request.url });
+    this.logger.info({ path: request.url }, 'Hello endpoint accessed');
     return { message: 'Hello world' };
   }
 }
@@ -460,6 +524,7 @@ The `NatsModule` is automatically included when you import `CoreModule` in your
 It provides a centralized NATS client for messaging, service calls, and pub/sub communication between Edifice microservices.
 
 **Features:**
+
 - Centralized NATS configuration and connection management.
 - Exports a configured NATS `ClientProxy` for messaging and service communication.
 - Supports pub/sub and request/response patterns using NestJS decorators (`EventPattern`, `MessagePattern`).
@@ -468,15 +533,18 @@ It provides a centralized NATS client for messaging, service calls, and pub/sub
 - Provides `EntNatsServiceClient` for calling external Edifice services (request/response).
 
 **How it works:**
+
 - The NATS client is initialized and injected by the core module.
 - You can inject `EntNatsServiceClient` to call external services.
 - You can use abstract subscriber classes (generated by the CLI) to handle incoming events and requests.
 
 **Where and when:**
+
 - The NATS system is initialized automatically at application startup by `CoreModule`.
 - No manual configuration is needed; all dependencies are wired by the core module.
 
 **Configuration:**
+
 - NATS connection parameters are set using environment variables:
   ```env
   NATS_URL=nats://localhost:4222
@@ -500,7 +568,10 @@ import { EntNatsServiceClient } from '@edifice.io/edifice-ent-client';
 export class CommunicationService {
   constructor(private readonly entServiceClient: EntNatsServiceClient) {}
 
-  async addLinkBetweenGroups(sourceGroupId: string, targetGroupId: string): Promise<boolean> {
+  async addLinkBetweenGroups(
+    sourceGroupId: string,
+    targetGroupId: string,
+  ): Promise<boolean> {
     const request = { startGroupId: sourceGroupId, endGroupId: targetGroupId };
     const response = await this.entServiceClient.addLinkBetweenGroups(request);
     return response.created ?? false;
@@ -513,7 +584,13 @@ export class CommunicationService {
 > This example shows how to subscribe to events or respond to service requests using NestJS decorators and abstract classes generated by the CLI.
 
 ```typescript
-import { EventPattern, MessagePattern, Payload, Ctx, NatsContext } from '@nestjs/microservices';
+import {
+  EventPattern,
+  MessagePattern,
+  Payload,
+  Ctx,
+  NatsContext,
+} from '@nestjs/microservices';
 
 // These abstract subscriber classes are generated by the CLI.
 // You should extend them to implement your own event/message handling logic.
@@ -521,40 +598,58 @@ import { EventPattern, MessagePattern, Payload, Ctx, NatsContext } from '@nestjs
 // Example: Subscribe to events
 export abstract class BrokerSubscriber {
   @EventPattern('directory.groups.deleted')
-  onGroupsDeleted(@Payload() data: GroupsDeletedDTO, @Ctx() context: NatsContext) {
+  onGroupsDeleted(
+    @Payload() data: GroupsDeletedDTO,
+    @Ctx() context: NatsContext,
+  ) {
     this.handleGroupsDeletedEvent(data, context.getSubject());
   }
-  abstract handleGroupsDeletedEvent(data: GroupsDeletedDTO, subject: string): void;
+  abstract handleGroupsDeletedEvent(
+    data: GroupsDeletedDTO,
+    subject: string,
+  ): void;
 }
 
 // Example: Respond to service requests
 export abstract class AudienceSubscriber {
   @MessagePattern('audience.check.right.communities.*')
-  onCheckResourceAccess(@Payload() request: CheckResourceAccessRequestDTO, @Ctx() ctx: NatsContext): Promise<CheckResourceAccessResponseDTO> {
+  onCheckResourceAccess(
+    @Payload() request: CheckResourceAccessRequestDTO,
+    @Ctx() ctx: NatsContext,
+  ): Promise<CheckResourceAccessResponseDTO> {
     return this.handleCheckAnnouncementAccess(request, ctx.getSubject());
   }
-  abstract handleCheckAnnouncementAccess(request: CheckResourceAccessRequestDTO, subject: string): Promise<CheckResourceAccessResponseDTO>;
+  abstract handleCheckAnnouncementAccess(
+    request: CheckResourceAccessRequestDTO,
+    subject: string,
+  ): Promise<CheckResourceAccessResponseDTO>;
 }
 
 // Example: Concrete implementation
-@Injectable()
+@Controller()
 export class MyBrokerSubscriber extends BrokerSubscriber {
   handleGroupsDeletedEvent(data: GroupsDeletedDTO, subject: string): void {
     // Your custom logic here
-    console.log(`Groups deleted: ${JSON.stringify(data)} from subject: ${subject}`);
+    console.log(
+      `Groups deleted: ${JSON.stringify(data)} from subject: ${subject}`,
+    );
   }
 }
 
-@Injectable()
+@Controller()
 export class MyAudienceSubscriber extends AudienceSubscriber {
-  async handleCheckAnnouncementAccess(request: CheckResourceAccessRequestDTO, subject: string): Promise<CheckResourceAccessResponseDTO> {
+  async handleCheckAnnouncementAccess(
+    request: CheckResourceAccessRequestDTO,
+    subject: string,
+  ): Promise<CheckResourceAccessResponseDTO> {
     // Your custom logic here
     return { accessGranted: true };
   }
 }
 ```
 
-**Note:**  
+**Note:**
+
 - You do not need to configure NATS manually; it is ready to use when you import `CoreModule`.
 - Use `EntNatsServiceClient` for external service calls, and abstract subscriber classes for pub/sub and request/response patterns.
 - The CLI can generate abstract subscriber classes to help you implement event and message handlers.
@@ -565,28 +660,38 @@ The `PermissionModule` is automatically included when you import `CoreModule` in
 It provides decorators and guards for workflow-based and admin authorization, enabling fine-grained access control for your endpoints.
 
 **Features:**
+
 - `@RequirePermission('PERMISSION_NAME')`: Restricts access to endpoints based on user workflow rights.
 - `@RequireAdmc()`: Restricts access to endpoints for super administrators (ADMC).
 - `@Public()`: Marks endpoints as public (no authentication required).
 - Guards (`PermissionGuard`, `AdmcGuard`) are applied globally by the core module.
 
 **How it works:**
+
 - Decorators set metadata on your controllers and endpoints.
 - Guards read this metadata and check the user's session and permissions.
 - Permissions are automatically registered at startup by the AppRegistry service.
 
 **Where and when:**
+
 - The permission system is initialized automatically at application startup by `CoreModule`.
 - No manual configuration is needed; all dependencies are wired by the core module.
 
 **Configuration:**
+
 - User permissions and roles are provided in the session object (`entSession`).
 - Workflow rights are defined in your business logic and registered via decorators.
 
 **Example:**
+
 ```typescript
 import { Controller, Get, Post } from '@nestjs/common';
-import { RequirePermission, RequireAdmc, Public, CoreModule } from '@edifice.io/edifice-nestjs-core';
+import {
+  RequirePermission,
+  RequireAdmc,
+  Public,
+  CoreModule,
+} from '@edifice.io/edifice-nestjs-core';
 
 @Module({
   imports: [CoreModule], // PermissionModule is included automatically
@@ -625,23 +730,28 @@ The `SessionModule` is automatically included when you import `CoreModule` in yo
 It provides middleware, decorators, and helpers for managing user sessions in your Edifice backend.
 
 **Features:**
+
 - Middleware to validate and attach user sessions to each request.
 - Session decorator (`@Session()`) to inject the session directly into your controller methods.
 - Exposes session information on the raw Fastify request object (`request.raw.entSession`).
 - Integrates with the ENT service via NATS for session validation and refresh.
 
 **How it works:**
+
 - The session middleware runs on every API request, validates the session via the ENT service, and attaches it to the request.
 - You can access the session in your controllers using either the `@Session()` decorator or directly from the request object.
 
 **Where and when:**
+
 - The session system is initialized automatically at application startup by `CoreModule`.
 - No manual configuration is needed; all dependencies are wired by the core module.
 
 **Configuration:**
+
 - Session validation uses the NATS connection provided by the core module.
 
 **Example:**
+
 ```typescript
 import { Controller, Get, Req } from '@nestjs/common';
 import { CoreModule, Session } from '@edifice.io/edifice-nestjs-core';
@@ -680,21 +790,25 @@ The `TimelineModule` is automatically included when you import `CoreModule` in y
 It provides services for registering notification templates and sending notifications to users via the Edifice timeline system.
 
 **Features:**
+
 - Register notification templates for your application.
 - Send notifications to users (with push, mail, and preview options).
 - Integrates with the ENT client and NATS for delivery.
 - Supports localization via the I18n service.
 
 **How it works:**
+
 - The `TimelineService` is initialized and injected by the core module.
 - You can register notification templates at startup or on demand.
 - You can send notifications to users by calling the service methods.
 
 **Where and when:**
+
 - The timeline system is initialized automatically at application startup by `CoreModule`.
 - No manual configuration is needed; all dependencies are wired by the core module.
 
 **Configuration:**
+
 - The application name (`APP_NAME`) must be set using environment variables.
 - Notification templates can be registered at module initialization or dynamically.
 
@@ -767,7 +881,6 @@ export class MyNotificationService implements OnModuleInit {
   constructor(private readonly timelineService: TimelineService) {}
 
   async onModuleInit() {
-    
     const templates: RegisterNotificationRequestDTO[] = [
       {
         notificationName: 'MY_EVENT',
@@ -782,9 +895,13 @@ export class MyNotificationService implements OnModuleInit {
 ```
 
 **Sending a notification:**
+
 ```typescript
 import { TimelineService } from '@edifice.io/edifice-nestjs-core';
-import { SessionDto, SendNotificationRequestDTO } from '@edifice.io/edifice-ent-client';
+import {
+  SessionDto,
+  SendNotificationRequestDTO,
+} from '@edifice.io/edifice-ent-client';
 
 @Injectable()
 export class MyService {
@@ -807,7 +924,8 @@ export class MyService {
 }
 ```
 
-**Note:**  
+**Note:**
+
 - You do not need to configure the timeline system manually; it is ready to use when you import `CoreModule`.
 - Notifications are localized using the I18n service and delivered via NATS and the ENT client.
 
@@ -817,16 +935,19 @@ The Swagger module is automatically enabled when you import `CoreModule` in your
 It provides an interactive OpenAPI documentation for your API, available at `/openapi`.
 
 **Features:**
+
 - Auto-generates OpenAPI documentation from your controllers and DTOs.
 - Serves the Swagger UI at `/openapi` by default.
 - Supports custom title, description, version, and server URL via environment variables.
 
 **How it works:**
+
 - On application startup, Swagger is configured and started automatically if `ENABLE_SWAGGER=true` (default).
 - The configuration is read from environment variables and injected via `ConfigService`.
 
 **Configuration:**
 Set the following environment variables to customize Swagger:
+
 ```env
 ENABLE_SWAGGER=true
 SWAGGER_SERVER_URL=https://api.example.com
@@ -854,9 +975,7 @@ import { Module } from '@nestjs/common';
 import { CoreModule } from '@edifice.io/edifice-nestjs-core';
 
 @Module({
-  imports: [
-    CoreModule,
-  ],
+  imports: [CoreModule],
 })
 export class AppModule {}
 ```
@@ -877,12 +996,14 @@ Each tool is available as a binary when you install `@edifice.io/edifice-nestjs-
 **Purpose:**  
 Generate MikroORM entity files from your PostgreSQL database schema.
 
-**Usage:**  
+**Usage:**
+
 ```bash
 pnpm edifice-generate-entities --schema <schema-name> [options]
 ```
 
 **Arguments:**
+
 - `--schema` (required): Name of the database schema to use for entity generation.
 - `--path`: Target directory for generated entities (default: `./src/entities`).
 - `--temp-dir`: Temporary directory for initial generation (default: `./src/temp/entities`).
@@ -890,6 +1011,7 @@ pnpm edifice-generate-entities --schema <schema-name> [options]
 - `--keep-temp`: Keep temporary directory after generation (`true` or `false`, default: `false`).
 
 **Examples:**
+
 ```bash
 pnpm edifice-generate-entities --schema community
 pnpm edifice-generate-entities --schema community --temp-dir ./src/temp --path ./src/entities
@@ -904,15 +1026,18 @@ pnpm edifice-generate-entities --schema community --keep-temp true
 **Purpose:**  
 Generate a build metadata file containing build date, git commit hash, and branch name.
 
-**Usage:**  
+**Usage:**
+
 ```bash
 pnpm edifice-generate-metadata <target-file-path>
 ```
 
 **Arguments:**
+
 - `<target-file-path>` (required): Path to the file where metadata will be written.
 
 **Example:**
+
 ```bash
 pnpm edifice-generate-metadata ./dist/metadata.txt
 ```
@@ -924,7 +1049,8 @@ pnpm edifice-generate-metadata ./dist/metadata.txt
 **Purpose:**  
 Synchronize DTO TypeScript definitions to K6-compatible types for API testing.
 
-**Usage:**  
+**Usage:**
+
 ```bash
 pnpm edifice-k6-sync-dto
 ```
@@ -934,11 +1060,13 @@ This script uses configuration constants for DTOs and output paths.
 You can adjust the paths in the script or via environment variables if supported.
 
 **Example:**
+
 ```bash
 pnpm edifice-k6-sync-dto
 ```
 
-**Details:**  
+**Details:**
+
 - Parses DTOs from `client/rest/src/dtos`.
 - Generates K6-compatible types in `types/generated`.
 - Excludes files named `index.ts` by default.
@@ -980,7 +1108,6 @@ pnpm lint
 
 - [@edifice.io/edifice-ent-client](https://github.com/edificeio/entcore) - Edifice ENT client library
 
-
 ## 🐛 Issues
 
 Report issues on [GitHub Issues](https://github.com/edificeio/edifice-nestjs-core/issues).

package/dist/bin/update-rn-version.d.ts

@@ -0,0 +1,2 @@
+#!/usr/bin/env node
+export {};