Refactor: Modularize Task Master CLI into Modules Directory
Simplified the Task Master CLI by organizing code into modules within the directory. **Why:** - **Better Organization:** Code is now grouped by function (AI, commands, dependencies, tasks, UI, utilities). - **Easier to Maintain:** Smaller modules are simpler to update and fix. - **Scalable:** New features can be added more easily in a structured way. **What Changed:** - Moved code from single _____ _ __ __ _ |_ _|_ _ ___| | __ | \/ | __ _ ___| |_ ___ _ __ | |/ _` / __| |/ / | |\/| |/ _` / __| __/ _ \ '__| | | (_| \__ \ < | | | | (_| \__ \ || __/ | |_|\__,_|___/_|\_\ |_| |_|\__,_|___/\__\___|_| by https://x.com/eyaltoledano ╭────────────────────────────────────────────╮ │ │ │ Version: 0.9.16 Project: Task Master │ │ │ ╰────────────────────────────────────────────╯ ╭─────────────────────╮ │ │ │ Task Master CLI │ │ │ ╰─────────────────────╯ ╭───────────────────╮ │ Task Generation │ ╰───────────────────╯ parse-prd --input=<file.txt> [--tasks=10] Generate tasks from a PRD document generate Create individual task files from tasks… ╭───────────────────╮ │ Task Management │ ╰───────────────────╯ list [--status=<status>] [--with-subtas… List all tasks with their status set-status --id=<id> --status=<status> Update task status (done, pending, etc.) update --from=<id> --prompt="<context>" Update tasks based on new requirements add-task --prompt="<text>" [--dependencies=… Add a new task using AI add-dependency --id=<id> --depends-on=<id> Add a dependency to a task remove-dependency --id=<id> --depends-on=<id> Remove a dependency from a task ╭──────────────────────────╮ │ Task Analysis & Detail │ ╰──────────────────────────╯ analyze-complexity [--research] [--threshold=5] Analyze tasks and generate expansion re… complexity-report [--file=<path>] Display the complexity analysis report expand --id=<id> [--num=5] [--research] [… Break down tasks into detailed subtasks expand --all [--force] [--research] Expand all pending tasks with subtasks clear-subtasks --id=<id> Remove subtasks from specified tasks ╭─────────────────────────────╮ │ Task Navigation & Viewing │ ╰─────────────────────────────╯ next Show the next task to work on based on … show <id> Display detailed information about a sp… ╭─────────────────────────╮ │ Dependency Management │ ╰─────────────────────────╯ validate-dependenci… Identify invalid dependencies without f… fix-dependencies Fix invalid dependencies automatically ╭─────────────────────────╮ │ Environment Variables │ ╰─────────────────────────╯ ANTHROPIC_API_KEY Your Anthropic API key Required MODEL Claude model to use Default: claude-3-7-sonn… MAX_TOKENS Maximum tokens for responses Default: 4000 TEMPERATURE Temperature for model responses Default: 0.7 PERPLEXITY_API_KEY Perplexity API key for research Optional PERPLEXITY_MODEL Perplexity model to use Default: sonar-small-onl… DEBUG Enable debug logging Default: false LOG_LEVEL Console output level (debug,info,warn,error) Default: info DEFAULT_SUBTASKS Default number of subtasks to generate Default: 3 DEFAULT_PRIORITY Default task priority Default: medium PROJECT_NAME Project name displayed in UI Default: Task Master file into these new modules: - : AI interactions (Claude, Perplexity) - : CLI command definitions (Commander.js) - : Task dependency handling - : Core task operations (create, list, update, etc.) - : User interface elements (display, formatting) - : Utility functions and configuration - : Exports all modules - Replaced direct use of _____ _ __ __ _ |_ _|_ _ ___| | __ | \/ | __ _ ___| |_ ___ _ __ | |/ _` / __| |/ / | |\/| |/ _` / __| __/ _ \ '__| | | (_| \__ \ < | | | | (_| \__ \ || __/ | |_|\__,_|___/_|\_\ |_| |_|\__,_|___/\__\___|_| by https://x.com/eyaltoledano ╭────────────────────────────────────────────╮ │ │ │ Version: 0.9.16 Project: Task Master │ │ │ ╰────────────────────────────────────────────╯ ╭─────────────────────╮ │ │ │ Task Master CLI │ │ │ ╰─────────────────────╯ ╭───────────────────╮ │ Task Generation │ ╰───────────────────╯ parse-prd --input=<file.txt> [--tasks=10] Generate tasks from a PRD document generate Create individual task files from tasks… ╭───────────────────╮ │ Task Management │ ╰───────────────────╯ list [--status=<status>] [--with-subtas… List all tasks with their status set-status --id=<id> --status=<status> Update task status (done, pending, etc.) update --from=<id> --prompt="<context>" Update tasks based on new requirements add-task --prompt="<text>" [--dependencies=… Add a new task using AI add-dependency --id=<id> --depends-on=<id> Add a dependency to a task remove-dependency --id=<id> --depends-on=<id> Remove a dependency from a task ╭──────────────────────────╮ │ Task Analysis & Detail │ ╰──────────────────────────╯ analyze-complexity [--research] [--threshold=5] Analyze tasks and generate expansion re… complexity-report [--file=<path>] Display the complexity analysis report expand --id=<id> [--num=5] [--research] [… Break down tasks into detailed subtasks expand --all [--force] [--research] Expand all pending tasks with subtasks clear-subtasks --id=<id> Remove subtasks from specified tasks ╭─────────────────────────────╮ │ Task Navigation & Viewing │ ╰─────────────────────────────╯ next Show the next task to work on based on … show <id> Display detailed information about a sp… ╭─────────────────────────╮ │ Dependency Management │ ╰─────────────────────────╯ validate-dependenci… Identify invalid dependencies without f… fix-dependencies Fix invalid dependencies automatically ╭─────────────────────────╮ │ Environment Variables │ ╰─────────────────────────╯ ANTHROPIC_API_KEY Your Anthropic API key Required MODEL Claude model to use Default: claude-3-7-sonn… MAX_TOKENS Maximum tokens for responses Default: 4000 TEMPERATURE Temperature for model responses Default: 0.7 PERPLEXITY_API_KEY Perplexity API key for research Optional PERPLEXITY_MODEL Perplexity model to use Default: sonar-small-onl… DEBUG Enable debug logging Default: false LOG_LEVEL Console output level (debug,info,warn,error) Default: info DEFAULT_SUBTASKS Default number of subtasks to generate Default: 3 DEFAULT_PRIORITY Default task priority Default: medium PROJECT_NAME Project name displayed in UI Default: Task Master with the global command (see ). - Updated documentation () to reflect the new command. **Benefits:** Code is now cleaner, easier to work with, and ready for future growth. Use the command (or ) to run the CLI. See for command details.
This commit is contained in:
@@ -16,69 +16,33 @@ Create the foundational data structure including:
|
||||
Verify that the tasks.json structure can be created, read, and validated. Test with sample data to ensure all fields are properly handled and that validation correctly identifies invalid structures.
|
||||
|
||||
# Subtasks:
|
||||
## Subtask ID: 1
|
||||
## Title: Design JSON Schema for tasks.json
|
||||
## Status: done
|
||||
## Dependencies: None
|
||||
## Description: Create a formal JSON Schema definition that validates the structure of the tasks.json file. The schema should enforce the data model specified in the PRD, including the Task Model and Tasks Collection Model with all required fields (id, title, description, status, dependencies, priority, details, testStrategy, subtasks). Include type validation, required fields, and constraints on enumerated values (like status and priority options).
|
||||
## Acceptance Criteria:
|
||||
- JSON Schema file is created with proper validation for all fields in the Task and Tasks Collection models
|
||||
- Schema validates that task IDs are unique integers
|
||||
- Schema enforces valid status values ("pending", "done", "deferred")
|
||||
- Schema enforces valid priority values ("high", "medium", "low")
|
||||
- Schema validates the nested structure of subtasks
|
||||
- Schema includes validation for the meta object with projectName, version, timestamps, etc.
|
||||
## 1. Design JSON Schema for tasks.json [done]
|
||||
### Dependencies: None
|
||||
### Description: Create a formal JSON Schema definition that validates the structure of the tasks.json file. The schema should enforce the data model specified in the PRD, including the Task Model and Tasks Collection Model with all required fields (id, title, description, status, dependencies, priority, details, testStrategy, subtasks). Include type validation, required fields, and constraints on enumerated values (like status and priority options).
|
||||
### Details:
|
||||
|
||||
## Subtask ID: 2
|
||||
## Title: Implement Task Model Classes
|
||||
## Status: done
|
||||
## Dependencies: 1.1 ✅
|
||||
## Description: Create JavaScript classes that represent the Task and Tasks Collection models. Implement constructor methods that validate input data, getter/setter methods for properties, and utility methods for common operations (like adding subtasks, changing status, etc.). These classes will serve as the programmatic interface to the task data structure.
|
||||
## Acceptance Criteria:
|
||||
- Task class with all required properties from the PRD
|
||||
- TasksCollection class that manages an array of Task objects
|
||||
- Methods for creating, retrieving, updating tasks
|
||||
- Methods for managing subtasks within a task
|
||||
- Input validation in constructors and setters
|
||||
- Proper TypeScript/JSDoc type definitions for all classes and methods
|
||||
|
||||
## Subtask ID: 3
|
||||
## Title: Create File System Operations for tasks.json
|
||||
## Status: done
|
||||
## Dependencies: 1.1 ✅, 1.2 ✅
|
||||
## Description: Implement functions to read from and write to the tasks.json file. These functions should handle file system operations asynchronously, manage file locking to prevent corruption during concurrent operations, and ensure atomic writes (using temporary files and rename operations). Include initialization logic to create a default tasks.json file if one doesn't exist.
|
||||
## Acceptance Criteria:
|
||||
- Asynchronous read function that parses tasks.json into model objects
|
||||
- Asynchronous write function that serializes model objects to tasks.json
|
||||
- File locking mechanism to prevent concurrent write operations
|
||||
- Atomic write operations to prevent file corruption
|
||||
- Initialization function that creates default tasks.json if not present
|
||||
- Functions properly handle relative and absolute paths
|
||||
## 2. Implement Task Model Classes [done]
|
||||
### Dependencies: 1 (done)
|
||||
### Description: Create JavaScript classes that represent the Task and Tasks Collection models. Implement constructor methods that validate input data, getter/setter methods for properties, and utility methods for common operations (like adding subtasks, changing status, etc.). These classes will serve as the programmatic interface to the task data structure.
|
||||
### Details:
|
||||
|
||||
|
||||
## 3. Create File System Operations for tasks.json [done]
|
||||
### Dependencies: 1 (done), 2 (done)
|
||||
### Description: Implement functions to read from and write to the tasks.json file. These functions should handle file system operations asynchronously, manage file locking to prevent corruption during concurrent operations, and ensure atomic writes (using temporary files and rename operations). Include initialization logic to create a default tasks.json file if one doesn't exist.
|
||||
### Details:
|
||||
|
||||
|
||||
## 4. Implement Validation Functions [done]
|
||||
### Dependencies: 1 (done), 2 (done)
|
||||
### Description: Create a comprehensive set of validation functions that can verify the integrity of the task data structure. These should include validation of individual tasks, validation of the entire tasks collection, dependency cycle detection, and validation of relationships between tasks. These functions will be used both when loading data and before saving to ensure data integrity.
|
||||
### Details:
|
||||
|
||||
|
||||
## 5. Implement Error Handling System [done]
|
||||
### Dependencies: 1 (done), 3 (done), 4 (done)
|
||||
### Description: Create a robust error handling system for file operations and data validation. Implement custom error classes for different types of errors (file not found, permission denied, invalid data, etc.), error logging functionality, and recovery mechanisms where appropriate. This system should provide clear, actionable error messages to users while maintaining system stability.
|
||||
### Details:
|
||||
|
||||
## Subtask ID: 4
|
||||
## Title: Implement Validation Functions
|
||||
## Status: done
|
||||
## Dependencies: 1.1 ✅, 1.2 ✅
|
||||
## Description: Create a comprehensive set of validation functions that can verify the integrity of the task data structure. These should include validation of individual tasks, validation of the entire tasks collection, dependency cycle detection, and validation of relationships between tasks. These functions will be used both when loading data and before saving to ensure data integrity.
|
||||
## Acceptance Criteria:
|
||||
- Functions to validate individual task objects against schema
|
||||
- Function to validate entire tasks collection
|
||||
- Dependency cycle detection algorithm
|
||||
- Validation of parent-child relationships in subtasks
|
||||
- Validation of task ID uniqueness
|
||||
- Functions return detailed error messages for invalid data
|
||||
- Unit tests covering various validation scenarios
|
||||
|
||||
## Subtask ID: 5
|
||||
## Title: Implement Error Handling System
|
||||
## Status: done
|
||||
## Dependencies: 1.1 ✅, 1.3 ✅, 1.4 ✅
|
||||
## Description: Create a robust error handling system for file operations and data validation. Implement custom error classes for different types of errors (file not found, permission denied, invalid data, etc.), error logging functionality, and recovery mechanisms where appropriate. This system should provide clear, actionable error messages to users while maintaining system stability.
|
||||
## Acceptance Criteria:
|
||||
- Custom error classes for different error types (FileError, ValidationError, etc.)
|
||||
- Consistent error format with error code, message, and details
|
||||
- Error logging functionality with configurable verbosity
|
||||
- Recovery mechanisms for common error scenarios
|
||||
- Graceful degradation when non-critical errors occur
|
||||
- User-friendly error messages that suggest solutions
|
||||
- Unit tests for error handling in various scenarios
|
||||
|
||||
Reference in New Issue
Block a user