feat: Persistent Configuration System #865

New issue

Closed

opened 2025-10-14 16:21:31 -06:00 by navan · 0 comments

navan commented

2025-10-14 16:21:31 -06:00

Owner

Originally created by @eriknelson on 4/26/2025

"Add a persistent configuration system to task-master-ai that allows users to customize and persist preferences across sessions and projects."

Motivation

Currently, task-master-ai uses default locations and behaviors that cannot be
easily customized, forcing users to adapt to the tool rather than the tool
adapting to their workflow. Users need the ability to configure artifact
locations, naming conventions, and other preferences to integrate the tool
seamlessly with their existing project structures. This is particularly
important for teams with established conventions or users working across
multiple projects with different organizational needs. A persistent
configuration system would significantly improve flexibility, user
satisfaction, and adoption in diverse environments.

Proposed Solution

Implement a hierarchical configuration system that allows users to:

High-level overview: Create a configuration management system with global and project-specific settings
Integration: Support both global (~/.config/taskmaster/config.json) and local (.tmrc) configuration files with appropriate precedence rules

High-Level Workflow

Design a configuration schema that covers common customization needs
Implement a configuration manager that can read from multiple sources with proper precedence
Create CLI commands for viewing and modifying configuration settings
Develop validation logic to prevent invalid configurations
Update all relevant commands to respect configuration settings
Add migration support for existing users

Key Elements

Command-line interface for setting and viewing configuration values
Support for global user preferences (~/.config/taskmaster/config.json)
Project-specific overrides via local configuration file ($PROJECT_ROOT/.tmrc)
Configuration hierarchy with clear precedence rules
Customizable paths for artifacts, including PRDs and tasks
Ability to set default values for common command options
Configuration validation to prevent errors

Example Workflow

$ tm config set tm-artifact-dir=tm
→ Configuration updated: tm-artifact-dir = "tm"

$ tm config set tm-prd-dir-name=prds
→ Configuration updated: tm-prd-dir-name = "prds"

$ tm config list
→ Global configuration:
→   tm-artifact-dir: "tm"
→   tm-prd-dir-name: "prds"
→   tm-task-dir-name: "tasks"
→   default-priority: "medium"

$ tm add-task "Create new feature"
→ Task created at tm/tasks/task-2025-04-26-001.md

Implementation Considerations

Configuration files should use a standard format (JSON/YAML) for easy editing
Need to handle backward compatibility for users without configuration
Should provide sensible defaults for all configurable options
May require refactoring code that currently uses hardcoded paths
Consider environment variable overrides for CI/CD environments
Implement proper error handling for missing or inaccessible configuration files
Consider security implications for sensitive configuration values

*Originally created by @eriknelson on 4/26/2025* > "Add a persistent configuration system to task-master-ai that allows users to customize and persist preferences across sessions and projects." ### Motivation Currently, task-master-ai uses default locations and behaviors that cannot be easily customized, forcing users to adapt to the tool rather than the tool adapting to their workflow. Users need the ability to configure artifact locations, naming conventions, and other preferences to integrate the tool seamlessly with their existing project structures. This is particularly important for teams with established conventions or users working across multiple projects with different organizational needs. A persistent configuration system would significantly improve flexibility, user satisfaction, and adoption in diverse environments. ### Proposed Solution Implement a hierarchical configuration system that allows users to: - High-level overview: Create a configuration management system with global and project-specific settings - Integration: Support both global (~/.config/taskmaster/config.json) and local (.tmrc) configuration files with appropriate precedence rules ### High-Level Workflow 1. Design a configuration schema that covers common customization needs 2. Implement a configuration manager that can read from multiple sources with proper precedence 3. Create CLI commands for viewing and modifying configuration settings 4. Develop validation logic to prevent invalid configurations 5. Update all relevant commands to respect configuration settings 6. Add migration support for existing users ### Key Elements - Command-line interface for setting and viewing configuration values - Support for global user preferences (~/.config/taskmaster/config.json) - Project-specific overrides via local configuration file ($PROJECT_ROOT/.tmrc) - Configuration hierarchy with clear precedence rules - Customizable paths for artifacts, including PRDs and tasks - Ability to set default values for common command options - Configuration validation to prevent errors ### Example Workflow ```shell $ tm config set tm-artifact-dir=tm → Configuration updated: tm-artifact-dir = "tm" $ tm config set tm-prd-dir-name=prds → Configuration updated: tm-prd-dir-name = "prds" $ tm config list → Global configuration: → tm-artifact-dir: "tm" → tm-prd-dir-name: "prds" → tm-task-dir-name: "tasks" → default-priority: "medium" $ tm add-task "Create new feature" → Task created at tm/tasks/task-2025-04-26-001.md ``` ### Implementation Considerations - Configuration files should use a standard format (JSON/YAML) for easy editing - Need to handle backward compatibility for users without configuration - Should provide sensible defaults for all configurable options - May require refactoring code that currently uses hardcoded paths - Consider environment variable overrides for CI/CD environments - Implement proper error handling for missing or inaccessible configuration files - Consider security implications for sensitive configuration values