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:
Eyal Toledano
@@ -1,7 +1,7 @@
|
||||
# Task ID: 16
|
||||
# Title: Create Configuration Management System
|
||||
# Status: done
|
||||
# Dependencies: 1 ✅, 2 ✅
|
||||
# Dependencies: ✅ 1 (done), ✅ 2 (done)
|
||||
# Priority: high
|
||||
# Description: Implement robust configuration handling with environment variables and .env files.
|
||||
# Details:
|
||||
@@ -18,77 +18,39 @@ Build configuration management including:
|
||||
Test configuration loading from various sources (environment variables, .env files). Verify that validation correctly identifies invalid configurations. Test that defaults are applied when values are missing.
|
||||
|
||||
# Subtasks:
|
||||
## Subtask ID: 1
|
||||
## Title: Implement Environment Variable Loading
|
||||
## Status: done
|
||||
## Dependencies: None
|
||||
## Description: Create a module that loads environment variables from process.env and makes them accessible throughout the application. Implement a hierarchical structure for configuration values with proper typing. Include support for required vs. optional variables and implement a validation mechanism to ensure critical environment variables are present.
|
||||
## Acceptance Criteria:
|
||||
- Function created to access environment variables with proper TypeScript typing
|
||||
- Support for required variables with validation
|
||||
- Default values provided for optional variables
|
||||
- Error handling for missing required variables
|
||||
- Unit tests verifying environment variable loading works correctly
|
||||
## 1. Implement Environment Variable Loading [done]
|
||||
### Dependencies: None
|
||||
### Description: Create a module that loads environment variables from process.env and makes them accessible throughout the application. Implement a hierarchical structure for configuration values with proper typing. Include support for required vs. optional variables and implement a validation mechanism to ensure critical environment variables are present.
|
||||
### Details:
|
||||
|
||||
## Subtask ID: 2
|
||||
## Title: Implement .env File Support
|
||||
## Status: done
|
||||
## Dependencies: 16.1 ✅
|
||||
## Description: Add support for loading configuration from .env files using dotenv or a similar library. Implement file detection, parsing, and merging with existing environment variables. Handle multiple environments (.env.development, .env.production, etc.) and implement proper error handling for file reading issues.
|
||||
## Acceptance Criteria:
|
||||
- Integration with dotenv or equivalent library
|
||||
- Support for multiple environment-specific .env files (.env.development, .env.production)
|
||||
- Proper error handling for missing or malformed .env files
|
||||
- Priority order established (process.env overrides .env values)
|
||||
- Unit tests verifying .env file loading and overriding behavior
|
||||
|
||||
## Subtask ID: 3
|
||||
## Title: Implement Configuration Validation
|
||||
## Status: done
|
||||
## Dependencies: 16.1 ✅, 16.2 ✅
|
||||
## Description: Create a validation system for configuration values using a schema validation library like Joi, Zod, or Ajv. Define schemas for all configuration categories (API keys, file paths, feature flags, etc.). Implement validation that runs at startup and provides clear error messages for invalid configurations.
|
||||
## Acceptance Criteria:
|
||||
- Schema validation implemented for all configuration values
|
||||
- Type checking and format validation for different value types
|
||||
- Comprehensive error messages that clearly identify validation failures
|
||||
- Support for custom validation rules for complex configuration requirements
|
||||
- Unit tests covering validation of valid and invalid configurations
|
||||
## 2. Implement .env File Support [done]
|
||||
### Dependencies: 1 (done)
|
||||
### Description: Add support for loading configuration from .env files using dotenv or a similar library. Implement file detection, parsing, and merging with existing environment variables. Handle multiple environments (.env.development, .env.production, etc.) and implement proper error handling for file reading issues.
|
||||
### Details:
|
||||
|
||||
## Subtask ID: 4
|
||||
## Title: Create Configuration Defaults and Override System
|
||||
## Status: done
|
||||
## Dependencies: 16.1 ✅, 16.2 ✅, 16.3 ✅
|
||||
## Description: Implement a system of sensible defaults for all configuration values with the ability to override them via environment variables or .env files. Create a unified configuration object that combines defaults, .env values, and environment variables with proper precedence. Implement a caching mechanism to avoid repeated environment lookups.
|
||||
## Acceptance Criteria:
|
||||
- Default configuration values defined for all settings
|
||||
- Clear override precedence (env vars > .env files > defaults)
|
||||
- Configuration object accessible throughout the application
|
||||
- Caching mechanism to improve performance
|
||||
- Unit tests verifying override behavior works correctly
|
||||
|
||||
## Subtask ID: 5
|
||||
## Title: Create .env.example Template
|
||||
## Status: done
|
||||
## Dependencies: 16.1 ✅, 16.2 ✅, 16.3 ✅, 16.4 ✅
|
||||
## Description: Generate a comprehensive .env.example file that documents all supported environment variables, their purpose, format, and default values. Include comments explaining the purpose of each variable and provide examples. Ensure sensitive values are not included but have clear placeholders.
|
||||
## Acceptance Criteria:
|
||||
- Complete .env.example file with all supported variables
|
||||
- Detailed comments explaining each variable's purpose and format
|
||||
- Clear placeholders for sensitive values (API_KEY=your-api-key-here)
|
||||
- Categorization of variables by function (API, logging, features, etc.)
|
||||
- Documentation on how to use the .env.example file
|
||||
## 3. Implement Configuration Validation [done]
|
||||
### Dependencies: 1 (done), 2 (done)
|
||||
### Description: Create a validation system for configuration values using a schema validation library like Joi, Zod, or Ajv. Define schemas for all configuration categories (API keys, file paths, feature flags, etc.). Implement validation that runs at startup and provides clear error messages for invalid configurations.
|
||||
### Details:
|
||||
|
||||
|
||||
## 4. Create Configuration Defaults and Override System [done]
|
||||
### Dependencies: 1 (done), 2 (done), 3 (done)
|
||||
### Description: Implement a system of sensible defaults for all configuration values with the ability to override them via environment variables or .env files. Create a unified configuration object that combines defaults, .env values, and environment variables with proper precedence. Implement a caching mechanism to avoid repeated environment lookups.
|
||||
### Details:
|
||||
|
||||
|
||||
## 5. Create .env.example Template [done]
|
||||
### Dependencies: 1 (done), 2 (done), 3 (done), 4 (done)
|
||||
### Description: Generate a comprehensive .env.example file that documents all supported environment variables, their purpose, format, and default values. Include comments explaining the purpose of each variable and provide examples. Ensure sensitive values are not included but have clear placeholders.
|
||||
### Details:
|
||||
|
||||
|
||||
## 6. Implement Secure API Key Handling [done]
|
||||
### Dependencies: 1 (done), 2 (done), 3 (done), 4 (done)
|
||||
### Description: Create a secure mechanism for handling sensitive configuration values like API keys. Implement masking of sensitive values in logs and error messages. Add validation for API key formats and implement a mechanism to detect and warn about insecure storage of API keys (e.g., committed to git). Add support for key rotation and refresh.
|
||||
### Details:
|
||||
|
||||
## Subtask ID: 6
|
||||
## Title: Implement Secure API Key Handling
|
||||
## Status: done
|
||||
## Dependencies: 16.1 ✅, 16.2 ✅, 16.3 ✅, 16.4 ✅
|
||||
## Description: Create a secure mechanism for handling sensitive configuration values like API keys. Implement masking of sensitive values in logs and error messages. Add validation for API key formats and implement a mechanism to detect and warn about insecure storage of API keys (e.g., committed to git). Add support for key rotation and refresh.
|
||||
## Acceptance Criteria:
|
||||
- Secure storage of API keys and sensitive configuration
|
||||
- Masking of sensitive values in logs and error messages
|
||||
- Validation of API key formats (length, character set, etc.)
|
||||
- Warning system for potentially insecure configuration practices
|
||||
- Support for key rotation without application restart
|
||||
- Unit tests verifying secure handling of sensitive configuration
|
||||
|
||||
These subtasks provide a comprehensive approach to implementing the configuration management system with a focus on security, validation, and developer experience. The tasks are sequenced to build upon each other logically, starting with basic environment variable support and progressing to more advanced features like secure API key handling.
|
||||
|
||||
Reference in New Issue
Block a user