fix(commands): implement manual creation mode for add-task command
- Add support for --title/-t and --description/-d flags in add-task command - Fix validation for manual creation mode (title + description) - Implement proper testing for both prompt and manual creation modes - Update testing documentation with Commander.js testing best practices - Add guidance on handling variable hoisting and module initialization issues Changeset: brave-doors-open.md
This commit is contained in:
32
tasks/task_056.txt
Normal file
32
tasks/task_056.txt
Normal file
@@ -0,0 +1,32 @@
|
||||
# Task ID: 56
|
||||
# Title: Refactor Task-Master Files into Node Module Structure
|
||||
# Status: pending
|
||||
# Dependencies: None
|
||||
# Priority: medium
|
||||
# Description: Restructure the task-master files by moving them from the project root into a proper node module structure to improve organization and maintainability.
|
||||
# Details:
|
||||
This task involves a significant refactoring of the task-master system to follow better Node.js module practices. Currently, task-master files are located in the project root, which creates clutter and doesn't follow best practices for Node.js applications. The refactoring should:
|
||||
|
||||
1. Create a dedicated directory structure within node_modules or as a local package
|
||||
2. Update all import/require paths throughout the codebase to reference the new module location
|
||||
3. Reorganize the files into a logical structure (lib/, utils/, commands/, etc.)
|
||||
4. Ensure the module has a proper package.json with dependencies and exports
|
||||
5. Update any build processes, scripts, or configuration files to reflect the new structure
|
||||
6. Maintain backward compatibility where possible to minimize disruption
|
||||
7. Document the new structure and any changes to usage patterns
|
||||
|
||||
This is a high-risk refactoring as it touches many parts of the system, so it should be approached methodically with frequent testing. Consider using a feature branch and implementing the changes incrementally rather than all at once.
|
||||
|
||||
# Test Strategy:
|
||||
Testing for this refactoring should be comprehensive to ensure nothing breaks during the restructuring:
|
||||
|
||||
1. Create a complete inventory of existing functionality through automated tests before starting
|
||||
2. Implement unit tests for each module to verify they function correctly in the new structure
|
||||
3. Create integration tests that verify the interactions between modules work as expected
|
||||
4. Test all CLI commands to ensure they continue to function with the new module structure
|
||||
5. Verify that all import/require statements resolve correctly
|
||||
6. Test on different environments (development, staging) to ensure compatibility
|
||||
7. Perform regression testing on all features that depend on task-master functionality
|
||||
8. Create a rollback plan and test it to ensure we can revert changes if critical issues arise
|
||||
9. Conduct performance testing to ensure the refactoring doesn't introduce overhead
|
||||
10. Have multiple developers test the changes on their local environments before merging
|
||||
67
tasks/task_057.txt
Normal file
67
tasks/task_057.txt
Normal file
@@ -0,0 +1,67 @@
|
||||
# Task ID: 57
|
||||
# Title: Enhance Task-Master CLI User Experience and Interface
|
||||
# Status: pending
|
||||
# Dependencies: None
|
||||
# Priority: medium
|
||||
# Description: Improve the Task-Master CLI's user experience by refining the interface, reducing verbose logging, and adding visual polish to create a more professional and intuitive tool.
|
||||
# Details:
|
||||
The current Task-Master CLI interface is functional but lacks polish and produces excessive log output. This task involves several key improvements:
|
||||
|
||||
1. Log Management:
|
||||
- Implement log levels (ERROR, WARN, INFO, DEBUG, TRACE)
|
||||
- Only show INFO and above by default
|
||||
- Add a --verbose flag to show all logs
|
||||
- Create a dedicated log file for detailed logs
|
||||
|
||||
2. Visual Enhancements:
|
||||
- Add a clean, branded header when the tool starts
|
||||
- Implement color-coding for different types of messages (success in green, errors in red, etc.)
|
||||
- Use spinners or progress indicators for operations that take time
|
||||
- Add clear visual separation between command input and output
|
||||
|
||||
3. Interactive Elements:
|
||||
- Add loading animations for longer operations
|
||||
- Implement interactive prompts for complex inputs instead of requiring all parameters upfront
|
||||
- Add confirmation dialogs for destructive operations
|
||||
|
||||
4. Output Formatting:
|
||||
- Format task listings in tables with consistent spacing
|
||||
- Implement a compact mode and a detailed mode for viewing tasks
|
||||
- Add visual indicators for task status (icons or colors)
|
||||
|
||||
5. Help and Documentation:
|
||||
- Enhance help text with examples and clearer descriptions
|
||||
- Add contextual hints for common next steps after commands
|
||||
|
||||
Use libraries like chalk, ora, inquirer, and boxen to implement these improvements. Ensure the interface remains functional in CI/CD environments where interactive elements might not be supported.
|
||||
|
||||
# Test Strategy:
|
||||
Testing should verify both functionality and user experience improvements:
|
||||
|
||||
1. Automated Tests:
|
||||
- Create unit tests for log level filtering functionality
|
||||
- Test that all commands still function correctly with the new UI
|
||||
- Verify that non-interactive mode works in CI environments
|
||||
- Test that verbose and quiet modes function as expected
|
||||
|
||||
2. User Experience Testing:
|
||||
- Create a test script that runs through common user flows
|
||||
- Capture before/after screenshots for visual comparison
|
||||
- Measure and compare the number of lines output for common operations
|
||||
|
||||
3. Usability Testing:
|
||||
- Have 3-5 team members perform specific tasks using the new interface
|
||||
- Collect feedback on clarity, ease of use, and visual appeal
|
||||
- Identify any confusion points or areas for improvement
|
||||
|
||||
4. Edge Case Testing:
|
||||
- Test in terminals with different color schemes and sizes
|
||||
- Verify functionality in environments without color support
|
||||
- Test with very large task lists to ensure formatting remains clean
|
||||
|
||||
Acceptance Criteria:
|
||||
- Log output is reduced by at least 50% in normal operation
|
||||
- All commands provide clear visual feedback about their progress and completion
|
||||
- Help text is comprehensive and includes examples
|
||||
- Interface is visually consistent across all commands
|
||||
- Tool remains fully functional in non-interactive environments
|
||||
63
tasks/task_058.txt
Normal file
63
tasks/task_058.txt
Normal file
@@ -0,0 +1,63 @@
|
||||
# Task ID: 58
|
||||
# Title: Implement Elegant Package Update Mechanism for Task-Master
|
||||
# Status: pending
|
||||
# Dependencies: None
|
||||
# Priority: medium
|
||||
# Description: Create a robust update mechanism that handles package updates gracefully, ensuring all necessary files are updated when the global package is upgraded.
|
||||
# Details:
|
||||
Develop a comprehensive update system with these components:
|
||||
|
||||
1. **Update Detection**: When task-master runs, check if the current version matches the installed version. If not, notify the user an update is available.
|
||||
|
||||
2. **Update Command**: Implement a dedicated `task-master update` command that:
|
||||
- Updates the global package (`npm -g task-master-ai@latest`)
|
||||
- Automatically runs necessary initialization steps
|
||||
- Preserves user configurations while updating system files
|
||||
|
||||
3. **Smart File Management**:
|
||||
- Create a manifest of core files with checksums
|
||||
- During updates, compare existing files with the manifest
|
||||
- Only overwrite files that have changed in the update
|
||||
- Preserve user-modified files with an option to merge changes
|
||||
|
||||
4. **Configuration Versioning**:
|
||||
- Add version tracking to configuration files
|
||||
- Implement migration paths for configuration changes between versions
|
||||
- Provide backward compatibility for older configurations
|
||||
|
||||
5. **Update Notifications**:
|
||||
- Add a non-intrusive notification when updates are available
|
||||
- Include a changelog summary of what's new
|
||||
|
||||
This system should work seamlessly with the existing `task-master init` command but provide a more automated and user-friendly update experience.
|
||||
|
||||
# Test Strategy:
|
||||
Test the update mechanism with these specific scenarios:
|
||||
|
||||
1. **Version Detection Test**:
|
||||
- Install an older version, then verify the system correctly detects when a newer version is available
|
||||
- Test with minor and major version changes
|
||||
|
||||
2. **Update Command Test**:
|
||||
- Verify `task-master update` successfully updates the global package
|
||||
- Confirm all necessary files are updated correctly
|
||||
- Test with and without user-modified files present
|
||||
|
||||
3. **File Preservation Test**:
|
||||
- Modify configuration files, then update
|
||||
- Verify user changes are preserved while system files are updated
|
||||
- Test with conflicts between user changes and system updates
|
||||
|
||||
4. **Rollback Test**:
|
||||
- Implement and test a rollback mechanism if updates fail
|
||||
- Verify system returns to previous working state
|
||||
|
||||
5. **Integration Test**:
|
||||
- Create a test project with the current version
|
||||
- Run through the update process
|
||||
- Verify all functionality continues to work after update
|
||||
|
||||
6. **Edge Case Tests**:
|
||||
- Test updating with insufficient permissions
|
||||
- Test updating with network interruptions
|
||||
- Test updating from very old versions to latest
|
||||
30
tasks/task_059.txt
Normal file
30
tasks/task_059.txt
Normal file
@@ -0,0 +1,30 @@
|
||||
# Task ID: 59
|
||||
# Title: Remove Manual Package.json Modifications and Implement Automatic Dependency Management
|
||||
# Status: pending
|
||||
# Dependencies: None
|
||||
# Priority: medium
|
||||
# Description: Eliminate code that manually modifies users' package.json files and implement proper npm dependency management that automatically handles package requirements when users install task-master-ai.
|
||||
# Details:
|
||||
Currently, the application is attempting to manually modify users' package.json files, which is not the recommended approach for npm packages. Instead:
|
||||
|
||||
1. Review all code that directly manipulates package.json files in users' projects
|
||||
2. Remove these manual modifications
|
||||
3. Properly define all dependencies in the package.json of task-master-ai itself
|
||||
4. Ensure all peer dependencies are correctly specified
|
||||
5. For any scripts that need to be available to users, use proper npm bin linking or npx commands
|
||||
6. Update the installation process to leverage npm's built-in dependency management
|
||||
7. If configuration is needed in users' projects, implement a proper initialization command that creates config files rather than modifying package.json
|
||||
8. Document the new approach in the README and any other relevant documentation
|
||||
|
||||
This change will make the package more reliable, follow npm best practices, and prevent potential conflicts or errors when modifying users' project files.
|
||||
|
||||
# Test Strategy:
|
||||
1. Create a fresh test project directory
|
||||
2. Install the updated task-master-ai package using npm install task-master-ai
|
||||
3. Verify that no code attempts to modify the test project's package.json
|
||||
4. Confirm all dependencies are properly installed in node_modules
|
||||
5. Test all commands to ensure they work without the previous manual package.json modifications
|
||||
6. Try installing in projects with various existing configurations to ensure no conflicts occur
|
||||
7. Test the uninstall process to verify it cleanly removes the package without leaving unwanted modifications
|
||||
8. Verify the package works in different npm environments (npm 6, 7, 8) and with different Node.js versions
|
||||
9. Create an integration test that simulates a real user workflow from installation through usage
|
||||
Reference in New Issue
Block a user