@sundaysf/cli-v2 1.0.1 → 1.0.3

package/dist/templates/module/.claude/agents/sundays-backend-builder.md

@@ -1,70 +1,70 @@
----
-name: sundays-backend-builder
-description: Use this agent when you need to create or modify backend components in a Sundays Framework project. This includes creating new controllers, routers, services, implementing CRUD operations, or ensuring existing code follows the framework's strict architectural patterns. <example>Context: User needs to create a new API endpoint for managing products. user: 'I need to create a products API with full CRUD operations' assistant: 'I'll use the sundays-backend-builder agent to create the products API following the Sundays Framework standards' <commentary>Since the user needs to create backend components following Sundays Framework patterns, use the sundays-backend-builder agent to ensure proper structure and implementation.</commentary></example> <example>Context: User wants to add pagination to an existing controller. user: 'Add pagination to the orders controller getAll method' assistant: 'Let me use the sundays-backend-builder agent to implement proper pagination using IBasePaginator' <commentary>The user needs to modify a controller to follow Sundays Framework pagination patterns, so the sundays-backend-builder agent should be used.</commentary></example> <example>Context: User needs to fix a controller that doesn't follow standards. user: 'The customer controller isn't following our standards, can you fix it?' assistant: 'I'll use the sundays-backend-builder agent to refactor the customer controller to match our Sundays Framework standards' <commentary>Since the controller needs to be refactored to follow framework standards, the sundays-backend-builder agent is appropriate.</commentary></example>
-model: sonnet
-color: blue
----
-
-You are an expert backend developer specializing in the Sundays Framework architecture. Your mission is to build and maintain backend components that strictly adhere to the framework's established patterns and conventions.
-
-**Core Responsibilities:**
-
-1. **Component Creation**: When creating new backend components, ALWAYS use `npm run create:controller` to scaffold the initial structure. This ensures consistency across the codebase.
-
-2. **Strict Structure Adherence**: You must follow these exact directory structures without deviation:
-   - Routes: `routes/<name>/<name>.router.ts`
-   - Controllers: `controllers/<name>/<name>.controller.ts`
-   - Services: `services/<name>/<name>.service.ts`
-   - DTOs: `dto/input/<entity>/<entity>.create.dto.ts` and `dto/input/<entity>/<entity>.update.dto.ts`
-
-3. **Interface Implementation**:
-   - ALL controllers MUST implement `IBaseController`
-   - ALL paginated getAll methods MUST use `IDataPaginator` (not IBasePaginator)
-   - ALWAYS use `paginationHelper` from `@sundaysf/utils` to extract page and limit from request
-
-4. **DAO/Service Pattern**:
-   - Initialize DAOs as private class members: `private _<entity>DAO: <Entity>DAO = new <Entity>DAO()`
-   - Follow the same pattern for services when applicable
-   - Use underscore prefix for private members
-
-5. **Method Implementation Standards**:
-   - **getAll**: Return paginated results using `IDataPaginator`, extract pagination with `paginationHelper(req)`
-   - **getByUuid**: Use UUID in params, convert to ID for DAO operations
-   - **create**: Validate with DTOs, generate UUID with `uuidv4()` in controller
-   - **update**: Get entity by UUID first to find ID, then update using DAO
-   - **delete**: Get entity by UUID first to find ID, then delete using DAO
-
-6. **Response Format**: ALL responses must follow:
-   ```json
-   {
-     "success": boolean,
-     "data": {...} // or "message": string
-   }
-   ```
-   Note: `IDataPaginator` already includes these fields, so don't double-wrap paginated responses.
-
-7. **Router Binding**: ALWAYS use `.bind(this._<entity>Controller)` when assigning controller methods to routes to maintain proper context.
-
-8. **Quality Checks**:
-   - Verify all imports are correct and from the right packages
-   - Ensure TypeScript types are properly defined
-   - Check that error handling uses `next(err)` pattern
-   - Validate that DTOs properly sanitize input data
-   - Confirm UUID generation happens in controller, not DTO or client-side
-
-**Working Process**:
-
-1. When creating new components, first run `npm run create:controller` command
-2. Analyze existing similar components in the project for pattern reference
-3. Implement following the exact structure found in existing code
-4. Ensure all naming conventions match (camelCase for variables, PascalCase for classes)
-5. Test that all CRUD operations follow the established patterns
-
-**Critical Rules**:
-- NEVER deviate from the established folder structure
-- NEVER create custom patterns - follow existing examples exactly
-- ALWAYS check existing implementations before creating new ones
-- ALWAYS maintain consistency with the project's CLAUDE.md guidelines
-- Be extremely meticulous about structure - it must be perfect
-
-Your code must be production-ready, following all Sundays Framework conventions to the letter. Every component you create or modify should seamlessly integrate with the existing architecture without requiring any adjustments to other parts of the system.
+---
+name: sundays-backend-builder
+description: Use this agent when you need to create or modify backend components in a Sundays Framework project. This includes creating new controllers, routers, services, implementing CRUD operations, or ensuring existing code follows the framework's strict architectural patterns. <example>Context: User needs to create a new API endpoint for managing products. user: 'I need to create a products API with full CRUD operations' assistant: 'I'll use the sundays-backend-builder agent to create the products API following the Sundays Framework standards' <commentary>Since the user needs to create backend components following Sundays Framework patterns, use the sundays-backend-builder agent to ensure proper structure and implementation.</commentary></example> <example>Context: User wants to add pagination to an existing controller. user: 'Add pagination to the orders controller getAll method' assistant: 'Let me use the sundays-backend-builder agent to implement proper pagination using IBasePaginator' <commentary>The user needs to modify a controller to follow Sundays Framework pagination patterns, so the sundays-backend-builder agent should be used.</commentary></example> <example>Context: User needs to fix a controller that doesn't follow standards. user: 'The customer controller isn't following our standards, can you fix it?' assistant: 'I'll use the sundays-backend-builder agent to refactor the customer controller to match our Sundays Framework standards' <commentary>Since the controller needs to be refactored to follow framework standards, the sundays-backend-builder agent is appropriate.</commentary></example>
+model: sonnet
+color: blue
+---
+
+You are an expert backend developer specializing in the Sundays Framework architecture. Your mission is to build and maintain backend components that strictly adhere to the framework's established patterns and conventions.
+
+**Core Responsibilities:**
+
+1. **Component Creation**: When creating new backend components, ALWAYS use `npm run create:controller` to scaffold the initial structure. This ensures consistency across the codebase.
+
+2. **Strict Structure Adherence**: You must follow these exact directory structures without deviation:
+   - Routes: `routes/<name>/<name>.router.ts`
+   - Controllers: `controllers/<name>/<name>.controller.ts`
+   - Services: `services/<name>/<name>.service.ts`
+   - DTOs: `dto/input/<entity>/<entity>.create.dto.ts` and `dto/input/<entity>/<entity>.update.dto.ts`
+
+3. **Interface Implementation**:
+   - ALL controllers MUST implement `IBaseController`
+   - ALL paginated getAll methods MUST use `IDataPaginator` (not IBasePaginator)
+   - ALWAYS use `paginationHelper` from `@sundaysf/utils` to extract page and limit from request
+
+4. **DAO/Service Pattern**:
+   - Initialize DAOs as private class members: `private _<entity>DAO: <Entity>DAO = new <Entity>DAO()`
+   - Follow the same pattern for services when applicable
+   - Use underscore prefix for private members
+
+5. **Method Implementation Standards**:
+   - **getAll**: Return paginated results using `IDataPaginator`, extract pagination with `paginationHelper(req)`
+   - **getByUuid**: Use UUID in params, convert to ID for DAO operations
+   - **create**: Validate with DTOs, generate UUID with `uuidv4()` in controller
+   - **update**: Get entity by UUID first to find ID, then update using DAO
+   - **delete**: Get entity by UUID first to find ID, then delete using DAO
+
+6. **Response Format**: ALL responses must follow:
+   ```json
+   {
+     "success": boolean,
+     "data": {...} // or "message": string
+   }
+   ```
+   Note: `IDataPaginator` already includes these fields, so don't double-wrap paginated responses.
+
+7. **Router Binding**: ALWAYS use `.bind(this._<entity>Controller)` when assigning controller methods to routes to maintain proper context.
+
+8. **Quality Checks**:
+   - Verify all imports are correct and from the right packages
+   - Ensure TypeScript types are properly defined
+   - Check that error handling uses `next(err)` pattern
+   - Validate that DTOs properly sanitize input data
+   - Confirm UUID generation happens in controller, not DTO or client-side
+
+**Working Process**:
+
+1. When creating new components, first run `npm run create:controller` command
+2. Analyze existing similar components in the project for pattern reference
+3. Implement following the exact structure found in existing code
+4. Ensure all naming conventions match (camelCase for variables, PascalCase for classes)
+5. Test that all CRUD operations follow the established patterns
+
+**Critical Rules**:
+- NEVER deviate from the established folder structure
+- NEVER create custom patterns - follow existing examples exactly
+- ALWAYS check existing implementations before creating new ones
+- ALWAYS maintain consistency with the project's CLAUDE.md guidelines
+- Be extremely meticulous about structure - it must be perfect
+
+Your code must be production-ready, following all Sundays Framework conventions to the letter. Every component you create or modify should seamlessly integrate with the existing architecture without requiring any adjustments to other parts of the system.

package/dist/templates/module/.claude/settings.local.json

@@ -1,10 +1,10 @@
-{
-  "permissions": {
-    "allow": [
-      "Bash(npm run build:*)",
-      "Bash(npm run format:*)"
-    ],
-    "deny": [],
-    "ask": []
-  }
-}
+{
+  "permissions": {
+    "allow": [
+      "Bash(npm run build:*)",
+      "Bash(npm run format:*)"
+    ],
+    "deny": [],
+    "ask": []
+  }
+}

package/dist/templates/module/CLAUDE.md

@@ -1,159 +1,159 @@
-# CLAUDE.md
-
-This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
-
-## Module Template Overview
-
-This is a basic npm module template created by the Sundays Framework SDK. It provides a minimal starting point for creating reusable Node.js modules.
-
-## Commands
-
-### Development
-
-- `npm run build` - Compile TypeScript to JavaScript (output to dist/)
-- `npm test` - Run tests (no test framework configured by default)
-- `npm run format` - Format code (if Prettier is configured)
-
-### Publishing
-
-- `npm run npm:publish` - Publish the module to npm registry
-
-## Project Structure
-
-```
-module/
-├── src/           # TypeScript source files
-│   └── index.ts   # Main entry point
-├── dist/          # Compiled JavaScript output (generated)
-├── tsconfig.json  # TypeScript configuration
-├── package.json   # Module metadata and dependencies
-└── .gitignore     # Git ignore patterns
-```
-
-## Configuration
-
-### TypeScript Setup
-
-The module is configured with TypeScript for type safety:
-- Source files in `src/`
-- Compiled output to `dist/`
-- Strict mode enabled
-- ES2020 target with CommonJS modules
-- Declaration files generated for TypeScript consumers
-
-### Package.json
-
-Key fields to configure:
-- `name`: Your module name (scoped or unscoped)
-- `version`: Semantic version (start with 0.1.0)
-- `description`: Brief description of the module
-- `main`: Entry point (usually `dist/index.js`)
-- `types`: TypeScript declarations (usually `dist/index.d.ts`)
-- `author`: Your name or organization
-- `license`: License type (MIT, ISC, etc.)
-
-## Getting Started
-
-1. **Initialize the module**:
-   ```bash
-   npm install
-   ```
-
-2. **Write your module code** in `src/index.ts`:
-   ```typescript
-   export function myFunction() {
-     return "Hello from my module!";
-   }
-   
-   export class MyClass {
-     // Your implementation
-   }
-   ```
-
-3. **Build the module**:
-   ```bash
-   npm run build
-   ```
-
-4. **Test locally** before publishing:
-   ```bash
-   npm link
-   # In another project:
-   npm link your-module-name
-   ```
-
-5. **Publish to npm**:
-   ```bash
-   npm run npm:publish
-   ```
-
-## Best Practices
-
-1. **Export Strategy**: Use named exports for clarity
-   ```typescript
-   export { MyClass, myFunction, MyInterface };
-   ```
-
-2. **Type Definitions**: Always include TypeScript definitions
-   - Helps consumers with IntelliSense
-   - Prevents type-related bugs
-
-3. **Documentation**: Add JSDoc comments to exported functions/classes
-   ```typescript
-   /**
-    * Calculates the sum of two numbers
-    * @param a First number
-    * @param b Second number
-    * @returns The sum of a and b
-    */
-   export function add(a: number, b: number): number {
-     return a + b;
-   }
-   ```
-
-4. **Versioning**: Follow semantic versioning (semver)
-   - MAJOR: Breaking changes
-   - MINOR: New features (backward compatible)
-   - PATCH: Bug fixes
-
-5. **Testing**: Consider adding a test framework
-   - Jest for unit testing
-   - Include test scripts in package.json
-
-6. **Dependencies**: Keep dependencies minimal
-   - Use `dependencies` for runtime requirements
-   - Use `devDependencies` for build/test tools
-   - Consider marking some as `peerDependencies`
-
-## Common Module Patterns
-
-### Singleton Pattern
-```typescript
-class MySingleton {
-  private static instance: MySingleton;
-  
-  private constructor() {}
-  
-  static getInstance(): MySingleton {
-    if (!MySingleton.instance) {
-      MySingleton.instance = new MySingleton();
-    }
-    return MySingleton.instance;
-  }
-}
-```
-
-### Factory Pattern
-```typescript
-export function createInstance(config: Config): MyClass {
-  return new MyClass(config);
-}
-```
-
-### Plugin/Extension Pattern
-```typescript
-export interface Plugin {
-  name: string;
-  install(app: any): void;
-}
+# CLAUDE.md
+
+This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
+
+## Module Template Overview
+
+This is a basic npm module template created by the Sundays Framework SDK. It provides a minimal starting point for creating reusable Node.js modules.
+
+## Commands
+
+### Development
+
+- `npm run build` - Compile TypeScript to JavaScript (output to dist/)
+- `npm test` - Run tests (no test framework configured by default)
+- `npm run format` - Format code (if Prettier is configured)
+
+### Publishing
+
+- `npm run npm:publish` - Publish the module to npm registry
+
+## Project Structure
+
+```
+module/
+├── src/           # TypeScript source files
+│   └── index.ts   # Main entry point
+├── dist/          # Compiled JavaScript output (generated)
+├── tsconfig.json  # TypeScript configuration
+├── package.json   # Module metadata and dependencies
+└── .gitignore     # Git ignore patterns
+```
+
+## Configuration
+
+### TypeScript Setup
+
+The module is configured with TypeScript for type safety:
+- Source files in `src/`
+- Compiled output to `dist/`
+- Strict mode enabled
+- ES2020 target with CommonJS modules
+- Declaration files generated for TypeScript consumers
+
+### Package.json
+
+Key fields to configure:
+- `name`: Your module name (scoped or unscoped)
+- `version`: Semantic version (start with 0.1.0)
+- `description`: Brief description of the module
+- `main`: Entry point (usually `dist/index.js`)
+- `types`: TypeScript declarations (usually `dist/index.d.ts`)
+- `author`: Your name or organization
+- `license`: License type (MIT, ISC, etc.)
+
+## Getting Started
+
+1. **Initialize the module**:
+   ```bash
+   npm install
+   ```
+
+2. **Write your module code** in `src/index.ts`:
+   ```typescript
+   export function myFunction() {
+     return "Hello from my module!";
+   }
+   
+   export class MyClass {
+     // Your implementation
+   }
+   ```
+
+3. **Build the module**:
+   ```bash
+   npm run build
+   ```
+
+4. **Test locally** before publishing:
+   ```bash
+   npm link
+   # In another project:
+   npm link your-module-name
+   ```
+
+5. **Publish to npm**:
+   ```bash
+   npm run npm:publish
+   ```
+
+## Best Practices
+
+1. **Export Strategy**: Use named exports for clarity
+   ```typescript
+   export { MyClass, myFunction, MyInterface };
+   ```
+
+2. **Type Definitions**: Always include TypeScript definitions
+   - Helps consumers with IntelliSense
+   - Prevents type-related bugs
+
+3. **Documentation**: Add JSDoc comments to exported functions/classes
+   ```typescript
+   /**
+    * Calculates the sum of two numbers
+    * @param a First number
+    * @param b Second number
+    * @returns The sum of a and b
+    */
+   export function add(a: number, b: number): number {
+     return a + b;
+   }
+   ```
+
+4. **Versioning**: Follow semantic versioning (semver)
+   - MAJOR: Breaking changes
+   - MINOR: New features (backward compatible)
+   - PATCH: Bug fixes
+
+5. **Testing**: Consider adding a test framework
+   - Jest for unit testing
+   - Include test scripts in package.json
+
+6. **Dependencies**: Keep dependencies minimal
+   - Use `dependencies` for runtime requirements
+   - Use `devDependencies` for build/test tools
+   - Consider marking some as `peerDependencies`
+
+## Common Module Patterns
+
+### Singleton Pattern
+```typescript
+class MySingleton {
+  private static instance: MySingleton;
+  
+  private constructor() {}
+  
+  static getInstance(): MySingleton {
+    if (!MySingleton.instance) {
+      MySingleton.instance = new MySingleton();
+    }
+    return MySingleton.instance;
+  }
+}
+```
+
+### Factory Pattern
+```typescript
+export function createInstance(config: Config): MyClass {
+  return new MyClass(config);
+}
+```
+
+### Plugin/Extension Pattern
+```typescript
+export interface Plugin {
+  name: string;
+  install(app: any): void;
+}
 ```

package/dist/templates/module/src/index.ts

@@ -1,9 +1,9 @@
-/**
- * Sundays Framework Module
- *
- * Replace this with your module exports.
- */
-
-export const hello = (): string => {
-  return 'Hello from Sundays module';
-};
+/**
+ * Sundays Framework Module
+ *
+ * Replace this with your module exports.
+ */
+
+export const hello = (): string => {
+  return 'Hello from Sundays module';
+};

package/dist/templates/module/tsconfig.json

@@ -1,19 +1,19 @@
-{
-  "compilerOptions": {
-    "target": "ES2022",
-    "module": "commonjs",
-    "lib": ["ES2022"],
-    "outDir": "./dist",
-    "rootDir": "./src",
-    "strict": true,
-    "esModuleInterop": true,
-    "skipLibCheck": true,
-    "forceConsistentCasingInFileNames": true,
-    "resolveJsonModule": true,
-    "declaration": true,
-    "declarationMap": true,
-    "sourceMap": true
-  },
-  "include": ["src/**/*"],
-  "exclude": ["node_modules", "dist"]
-}
+{
+  "compilerOptions": {
+    "target": "ES2022",
+    "module": "commonjs",
+    "lib": ["ES2022"],
+    "outDir": "./dist",
+    "rootDir": "./src",
+    "strict": true,
+    "esModuleInterop": true,
+    "skipLibCheck": true,
+    "forceConsistentCasingInFileNames": true,
+    "resolveJsonModule": true,
+    "declaration": true,
+    "declarationMap": true,
+    "sourceMap": true
+  },
+  "include": ["src/**/*"],
+  "exclude": ["node_modules", "dist"]
+}

package/package.json

@@ -1,40 +1,40 @@
-{
-  "name": "@sundaysf/cli-v2",
-  "version": "1.0.1",
-  "description": "Sundays Framework CLI - Project scaffolding and CRUD code generation",
-  "main": "./dist/bin/index.js",
-  "scripts": {
-    "test": "jest",
-    "build": "gulp build",
-    "prepublishOnly": "npm run build"
-  },
-  "bin": {
-    "sundaysf": "./dist/bin/index.js"
-  },
-  "type": "module",
-  "engines": {
-    "node": ">=18.0.0"
-  },
-  "files": [
-    "dist/",
-    "README.md",
-    "LICENSE"
-  ],
-  "dependencies": {
-    "commander": "^11.0.0",
-    "fs-extra": "^11.1.1",
-    "inquirer": "^9.2.7",
-    "ora": "^8.2.0",
-    "ts-case-convert": "^2.1.0",
-    "uuid": "^11.1.0"
-  },
-  "devDependencies": {
-    "gulp": "^5.0.0",
-    "gulp-if": "^3.0.0",
-    "gulp-sourcemaps": "^3.0.0",
-    "gulp-terser": "^2.1.0",
-    "through2": "^4.0.2"
-  },
-  "author": "Pablo Dominguez",
-  "license": "MIT"
-}
+{
+  "name": "@sundaysf/cli-v2",
+  "version": "1.0.3",
+  "description": "Sundays Framework CLI - Project scaffolding and CRUD code generation",
+  "main": "./dist/bin/index.js",
+  "scripts": {
+    "test": "jest",
+    "build": "gulp build",
+    "prepublishOnly": "npm run build"
+  },
+  "bin": {
+    "sundaysf": "./dist/bin/index.js"
+  },
+  "type": "module",
+  "engines": {
+    "node": ">=18.0.0"
+  },
+  "files": [
+    "dist/",
+    "README.md",
+    "LICENSE"
+  ],
+  "dependencies": {
+    "commander": "^11.0.0",
+    "fs-extra": "^11.1.1",
+    "inquirer": "^9.2.7",
+    "ora": "^8.2.0",
+    "ts-case-convert": "^2.1.0",
+    "uuid": "^11.1.0"
+  },
+  "devDependencies": {
+    "gulp": "^5.0.0",
+    "gulp-if": "^3.0.0",
+    "gulp-sourcemaps": "^3.0.0",
+    "gulp-terser": "^2.1.0",
+    "through2": "^4.0.2"
+  },
+  "author": "Pablo Dominguez",
+  "license": "MIT"
+}