chore: Remove unused imports across modules
Removes unused import statements identified after the major refactoring of the AI service layer and other components. This cleanup improves code clarity and removes unnecessary dependencies.
Unused imports removed from:
- **`mcp-server/src/core/direct-functions/analyze-task-complexity.js`:**
- Removed `path`
- **`mcp-server/src/core/direct-functions/complexity-report.js`:**
- Removed `path`
- **`mcp-server/src/core/direct-functions/expand-all-tasks.js`:**
- Removed `path`, `fs`
- **`mcp-server/src/core/direct-functions/generate-task-files.js`:**
- Removed `path`
- **`mcp-server/src/core/direct-functions/parse-prd.js`:**
- Removed `os`, `findTasksJsonPath`
- **`mcp-server/src/core/direct-functions/update-tasks.js`:**
- Removed `isSilentMode`
- **`mcp-server/src/tools/add-task.js`:**
- Removed `createContentResponse`, `executeTaskMasterCommand`
- **`mcp-server/src/tools/analyze.js`:**
- Removed `getProjectRootFromSession` (as `projectRoot` is now required in args)
- **`mcp-server/src/tools/expand-task.js`:**
- Removed `path`
- **`mcp-server/src/tools/initialize-project.js`:**
- Removed `createContentResponse`
- **`mcp-server/src/tools/parse-prd.js`:**
- Removed `findPRDDocumentPath`, `resolveTasksOutputPath` (logic moved or handled by `resolveProjectPaths`)
- **`mcp-server/src/tools/update.js`:**
- Removed `getProjectRootFromSession` (as `projectRoot` is now required in args)
- **`scripts/modules/commands.js`:**
- Removed `exec`, `readline`
- Removed AI config getters (`getMainModelId`, etc.)
- Removed MCP helpers (`getMcpApiKeyStatus`)
- **`scripts/modules/config-manager.js`:**
- Removed `ZodError`, `readJSON`, `writeJSON`
- **`scripts/modules/task-manager/analyze-task-complexity.js`:**
- Removed AI config getters (`getMainModelId`, etc.)
- **`scripts/modules/task-manager/expand-all-tasks.js`:**
- Removed `fs`, `path`, `writeJSON`
- **`scripts/modules/task-manager/models.js`:**
- Removed `VALID_PROVIDERS`
- **`scripts/modules/task-manager/update-subtask-by-id.js`:**
- Removed AI config getters (`getMainModelId`, etc.)
- **`scripts/modules/task-manager/update-tasks.js`:**
- Removed AI config getters (`getMainModelId`, etc.)
- **`scripts/modules/ui.js`:**
- Removed `getDebugFlag`
- **`scripts/modules/utils.js`:**
- Removed `ZodError`
This commit is contained in:
Eyal Toledano
@@ -9,7 +9,6 @@ import {
|
||||
isSilentMode
|
||||
} from '../../../../scripts/modules/utils.js';
|
||||
import fs from 'fs';
|
||||
import path from 'path';
|
||||
|
||||
/**
|
||||
* Analyze task complexity and generate recommendations
|
||||
|
||||
@@ -9,7 +9,6 @@ import {
|
||||
disableSilentMode
|
||||
} from '../../../../scripts/modules/utils.js';
|
||||
import { getCachedOrExecute } from '../../tools/utils.js';
|
||||
import path from 'path';
|
||||
|
||||
/**
|
||||
* Direct function wrapper for displaying the complexity report with error handling and caching.
|
||||
|
||||
@@ -8,8 +8,6 @@ import {
|
||||
disableSilentMode,
|
||||
isSilentMode
|
||||
} from '../../../../scripts/modules/utils.js';
|
||||
import path from 'path';
|
||||
import fs from 'fs';
|
||||
|
||||
/**
|
||||
* Expand all pending tasks with subtasks (Direct Function Wrapper)
|
||||
|
||||
@@ -8,7 +8,6 @@ import {
|
||||
enableSilentMode,
|
||||
disableSilentMode
|
||||
} from '../../../../scripts/modules/utils.js';
|
||||
import path from 'path';
|
||||
|
||||
/**
|
||||
* Direct function wrapper for generateTaskFiles with error handling.
|
||||
|
||||
@@ -5,9 +5,7 @@
|
||||
|
||||
import path from 'path';
|
||||
import fs from 'fs';
|
||||
import os from 'os'; // Import os module for home directory check
|
||||
import { parsePRD } from '../../../../scripts/modules/task-manager.js';
|
||||
import { findTasksJsonPath } from '../utils/path-utils.js';
|
||||
import {
|
||||
enableSilentMode,
|
||||
disableSilentMode
|
||||
|
||||
@@ -6,8 +6,7 @@
|
||||
import { updateTasks } from '../../../../scripts/modules/task-manager.js';
|
||||
import {
|
||||
enableSilentMode,
|
||||
disableSilentMode,
|
||||
isSilentMode
|
||||
disableSilentMode
|
||||
} from '../../../../scripts/modules/utils.js';
|
||||
|
||||
/**
|
||||
|
||||
@@ -6,9 +6,7 @@
|
||||
import { z } from 'zod';
|
||||
import {
|
||||
createErrorResponse,
|
||||
createContentResponse,
|
||||
getProjectRootFromSession,
|
||||
executeTaskMasterCommand,
|
||||
handleApiResult
|
||||
} from './utils.js';
|
||||
import { addTaskDirect } from '../core/task-master-core.js';
|
||||
|
||||
@@ -4,11 +4,7 @@
|
||||
*/
|
||||
|
||||
import { z } from 'zod';
|
||||
import {
|
||||
handleApiResult,
|
||||
createErrorResponse,
|
||||
getProjectRootFromSession
|
||||
} from './utils.js';
|
||||
import { handleApiResult, createErrorResponse } from './utils.js';
|
||||
import { analyzeTaskComplexityDirect } from '../core/direct-functions/analyze-task-complexity.js';
|
||||
import { findTasksJsonPath } from '../core/utils/path-utils.js';
|
||||
import path from 'path';
|
||||
|
||||
@@ -11,7 +11,6 @@ import {
|
||||
} from './utils.js';
|
||||
import { expandTaskDirect } from '../core/direct-functions/expand-task.js';
|
||||
import { findTasksJsonPath } from '../core/utils/path-utils.js';
|
||||
import path from 'path';
|
||||
|
||||
/**
|
||||
* Register the expand-task tool with the MCP server
|
||||
|
||||
@@ -1,9 +1,5 @@
|
||||
import { z } from 'zod';
|
||||
import {
|
||||
createContentResponse,
|
||||
createErrorResponse,
|
||||
handleApiResult
|
||||
} from './utils.js';
|
||||
import { createErrorResponse, handleApiResult } from './utils.js';
|
||||
import { initializeProjectDirect } from '../core/task-master-core.js';
|
||||
|
||||
export function registerInitializeProjectTool(server) {
|
||||
|
||||
@@ -10,11 +10,7 @@ import {
|
||||
createErrorResponse
|
||||
} from './utils.js';
|
||||
import { parsePRDDirect } from '../core/task-master-core.js';
|
||||
import {
|
||||
resolveProjectPaths,
|
||||
findPRDDocumentPath,
|
||||
resolveTasksOutputPath
|
||||
} from '../core/utils/path-utils.js';
|
||||
import { resolveProjectPaths } from '../core/utils/path-utils.js';
|
||||
|
||||
/**
|
||||
* Register the parsePRD tool with the MCP server
|
||||
|
||||
@@ -4,11 +4,7 @@
|
||||
*/
|
||||
|
||||
import { z } from 'zod';
|
||||
import {
|
||||
handleApiResult,
|
||||
createErrorResponse,
|
||||
getProjectRootFromSession
|
||||
} from './utils.js';
|
||||
import { handleApiResult, createErrorResponse } from './utils.js';
|
||||
import { updateTasksDirect } from '../core/task-master-core.js';
|
||||
import { findTasksJsonPath } from '../core/utils/path-utils.js';
|
||||
import path from 'path';
|
||||
|
||||
@@ -11,8 +11,6 @@ import fs from 'fs';
|
||||
import https from 'https';
|
||||
import inquirer from 'inquirer';
|
||||
import Table from 'cli-table3';
|
||||
import { exec } from 'child_process';
|
||||
import readline from 'readline';
|
||||
|
||||
import { log, readJSON } from './utils.js';
|
||||
import {
|
||||
@@ -43,16 +41,7 @@ import {
|
||||
} from './dependency-manager.js';
|
||||
|
||||
import {
|
||||
getMainModelId,
|
||||
getResearchModelId,
|
||||
getFallbackModelId,
|
||||
getAvailableModels,
|
||||
VALID_PROVIDERS,
|
||||
getMainProvider,
|
||||
getResearchProvider,
|
||||
getFallbackProvider,
|
||||
isApiKeySet,
|
||||
getMcpApiKeyStatus,
|
||||
getDebugFlag,
|
||||
getConfig,
|
||||
writeConfig,
|
||||
|
||||
@@ -2,14 +2,7 @@ import fs from 'fs';
|
||||
import path from 'path';
|
||||
import chalk from 'chalk';
|
||||
import { fileURLToPath } from 'url';
|
||||
import { ZodError } from 'zod';
|
||||
import {
|
||||
log,
|
||||
readJSON,
|
||||
writeJSON,
|
||||
resolveEnvVariable,
|
||||
findProjectRoot
|
||||
} from './utils.js';
|
||||
import { log, resolveEnvVariable, findProjectRoot } from './utils.js';
|
||||
|
||||
// Calculate __dirname in ESM
|
||||
const __filename = fileURLToPath(import.meta.url);
|
||||
|
||||
@@ -257,7 +257,7 @@
|
||||
"allowed_roles": ["main", "fallback"]
|
||||
}
|
||||
],
|
||||
"grok": [
|
||||
"xai": [
|
||||
{
|
||||
"id": "grok3",
|
||||
"swe_score": 0,
|
||||
|
||||
@@ -8,17 +8,7 @@ import { startLoadingIndicator, stopLoadingIndicator } from '../ui.js';
|
||||
|
||||
import { generateTextService } from '../ai-services-unified.js';
|
||||
|
||||
import {
|
||||
getDebugFlag,
|
||||
getProjectName,
|
||||
getMainModelId,
|
||||
getMainMaxTokens,
|
||||
getMainTemperature,
|
||||
getResearchModelId,
|
||||
getResearchMaxTokens,
|
||||
getResearchTemperature,
|
||||
getDefaultSubtasks
|
||||
} from '../config-manager.js';
|
||||
import { getDebugFlag, getProjectName } from '../config-manager.js';
|
||||
|
||||
/**
|
||||
* Generates the prompt for complexity analysis.
|
||||
|
||||
@@ -1,6 +1,4 @@
|
||||
import fs from 'fs';
|
||||
import path from 'path';
|
||||
import { log, readJSON, writeJSON, isSilentMode } from '../utils.js';
|
||||
import { log, readJSON, isSilentMode } from '../utils.js';
|
||||
import { startLoadingIndicator, stopLoadingIndicator } from '../ui.js';
|
||||
import expandTask from './expand-task.js';
|
||||
import { getDebugFlag } from '../config-manager.js';
|
||||
|
||||
@@ -10,7 +10,6 @@ import {
|
||||
getResearchModelId,
|
||||
getFallbackModelId,
|
||||
getAvailableModels,
|
||||
VALID_PROVIDERS,
|
||||
getMainProvider,
|
||||
getResearchProvider,
|
||||
getFallbackProvider,
|
||||
|
||||
@@ -17,7 +17,7 @@ import {
|
||||
isSilentMode
|
||||
} from '../utils.js';
|
||||
import { generateTextService } from '../ai-services-unified.js';
|
||||
import { getDebugFlag, isApiKeySet } from '../config-manager.js';
|
||||
import { getDebugFlag } from '../config-manager.js';
|
||||
import generateTaskFiles from './generate-task-files.js';
|
||||
|
||||
/**
|
||||
|
||||
@@ -18,15 +18,7 @@ import {
|
||||
stopLoadingIndicator
|
||||
} from '../ui.js';
|
||||
|
||||
import {
|
||||
getDebugFlag,
|
||||
getResearchModelId,
|
||||
getResearchTemperature,
|
||||
getResearchMaxTokens,
|
||||
getMainModelId,
|
||||
getMainMaxTokens,
|
||||
getMainTemperature
|
||||
} from '../config-manager.js';
|
||||
import { getDebugFlag } from '../config-manager.js';
|
||||
import generateTaskFiles from './generate-task-files.js';
|
||||
import { generateTextService } from '../ai-services-unified.js';
|
||||
|
||||
|
||||
@@ -9,21 +9,11 @@ import boxen from 'boxen';
|
||||
import ora from 'ora';
|
||||
import Table from 'cli-table3';
|
||||
import gradient from 'gradient-string';
|
||||
import {
|
||||
log,
|
||||
findTaskById,
|
||||
readJSON,
|
||||
readComplexityReport,
|
||||
truncate
|
||||
} from './utils.js';
|
||||
import { log, findTaskById, readJSON, truncate } from './utils.js';
|
||||
import path from 'path';
|
||||
import fs from 'fs';
|
||||
import { findNextTask, analyzeTaskComplexity } from './task-manager.js';
|
||||
import {
|
||||
getProjectName,
|
||||
getDebugFlag,
|
||||
getDefaultSubtasks
|
||||
} from './config-manager.js';
|
||||
import { getProjectName, getDefaultSubtasks } from './config-manager.js';
|
||||
|
||||
// Create a color gradient for the banner
|
||||
const coolGradient = gradient(['#00b4d8', '#0077b6', '#03045e']);
|
||||
|
||||
@@ -6,7 +6,6 @@
|
||||
import fs from 'fs';
|
||||
import path from 'path';
|
||||
import chalk from 'chalk';
|
||||
import { ZodError } from 'zod';
|
||||
// Import specific config getters needed here
|
||||
import { getLogLevel, getDebugFlag } from './config-manager.js';
|
||||
|
||||
|
||||
@@ -2149,7 +2149,7 @@ These enhancements ensure the refactored file is robust, maintainable, and align
|
||||
These enhancements ensure robust validation, unified service usage, and maintainable, predictable batch update behavior.
|
||||
</info added on 2025-04-24T17:49:25.126Z>
|
||||
|
||||
## 42. Remove all unused imports [pending]
|
||||
## 42. Remove all unused imports [done]
|
||||
### Dependencies: None
|
||||
### Description:
|
||||
### Details:
|
||||
@@ -2167,3 +2167,44 @@ These enhancements ensure robust validation, unified service usage, and maintain
|
||||
### Details:
|
||||
|
||||
|
||||
## 45. Add support for Bedrock provider with ai sdk and unified service [pending]
|
||||
### Dependencies: None
|
||||
### Description:
|
||||
### Details:
|
||||
|
||||
|
||||
<info added on 2025-04-25T19:03:42.584Z>
|
||||
- Install the Bedrock provider for the AI SDK using your package manager (e.g., npm i @ai-sdk/amazon-bedrock) and ensure the core AI SDK is present[3][4].
|
||||
|
||||
- To integrate with your existing config manager, externalize all Bedrock-specific configuration (such as region, model name, and credential provider) into your config management system. For example, store values like region ("us-east-1") and model identifier ("meta.llama3-8b-instruct-v1:0") in your config files or environment variables, and load them at runtime.
|
||||
|
||||
- For credentials, leverage the AWS SDK credential provider chain to avoid hardcoding secrets. Use the @aws-sdk/credential-providers package and pass a credentialProvider (e.g., fromNodeProviderChain()) to the Bedrock provider. This allows your config manager to control credential sourcing via environment, profiles, or IAM roles, consistent with other AWS integrations[1].
|
||||
|
||||
- Example integration with config manager:
|
||||
```js
|
||||
import { createAmazonBedrock } from '@ai-sdk/amazon-bedrock';
|
||||
import { fromNodeProviderChain } from '@aws-sdk/credential-providers';
|
||||
|
||||
// Assume configManager.get returns your config values
|
||||
const region = configManager.get('bedrock.region');
|
||||
const model = configManager.get('bedrock.model');
|
||||
|
||||
const bedrock = createAmazonBedrock({
|
||||
region,
|
||||
credentialProvider: fromNodeProviderChain(),
|
||||
});
|
||||
|
||||
// Use with AI SDK methods
|
||||
const { text } = await generateText({
|
||||
model: bedrock(model),
|
||||
prompt: 'Your prompt here',
|
||||
});
|
||||
```
|
||||
|
||||
- If your config manager supports dynamic provider selection, you can abstract the provider initialization so switching between Bedrock and other providers (like OpenAI or Anthropic) is seamless.
|
||||
|
||||
- Be aware that Bedrock exposes multiple models from different vendors, each with potentially different API behaviors. Your config should allow specifying the exact model string, and your integration should handle any model-specific options or response formats[5].
|
||||
|
||||
- For unified service integration, ensure your service layer can route requests to Bedrock using the configured provider instance, and normalize responses if you support multiple AI backends.
|
||||
</info added on 2025-04-25T19:03:42.584Z>
|
||||
|
||||
|
||||
11
tasks/task_065.txt
Normal file
11
tasks/task_065.txt
Normal file
@@ -0,0 +1,11 @@
|
||||
# Task ID: 65
|
||||
# Title: Add Bun Support for Taskmaster Installation
|
||||
# Status: pending
|
||||
# Dependencies: None
|
||||
# Priority: medium
|
||||
# Description: Implement full support for installing and managing Taskmaster using the Bun package manager, ensuring the installation process and user experience are identical to npm, pnpm, and Yarn.
|
||||
# Details:
|
||||
Update the Taskmaster installation scripts and documentation to support Bun as a first-class package manager. Ensure that users can install Taskmaster and run all CLI commands (including 'init' via scripts/init.js) using Bun, with the same directory structure, template copying, package.json merging, and MCP config setup as with npm, pnpm, and Yarn. Verify that all dependencies are compatible with Bun and that any Bun-specific configuration (such as lockfile handling or binary linking) is handled correctly. If the installation process includes a website or account setup, document and test these flows for parity; if not, explicitly confirm and document that no such steps are required. Update all relevant documentation and installation guides to include Bun instructions for macOS, Linux, and Windows (including WSL and PowerShell). Address any known Bun-specific issues (e.g., sporadic install hangs) with clear troubleshooting guidance.
|
||||
|
||||
# Test Strategy:
|
||||
1. Install Taskmaster using Bun on macOS, Linux, and Windows (including WSL and PowerShell), following the updated documentation. 2. Run the full installation and initialization process, verifying that the directory structure, templates, and MCP config are set up identically to npm, pnpm, and Yarn. 3. Execute all CLI commands (including 'init') and confirm functional parity. 4. If a website or account setup is required, test these flows for consistency; if not, confirm and document this. 5. Check for Bun-specific issues (e.g., install hangs) and verify that troubleshooting steps are effective. 6. Ensure the documentation is clear, accurate, and up to date for all supported platforms.
|
||||
61
tasks/task_066.txt
Normal file
61
tasks/task_066.txt
Normal file
@@ -0,0 +1,61 @@
|
||||
# Task ID: 66
|
||||
# Title: Support Status Filtering in Show Command for Subtasks
|
||||
# Status: pending
|
||||
# Dependencies: None
|
||||
# Priority: medium
|
||||
# Description: Enhance the 'show' command to accept a status parameter that filters subtasks by their current status, allowing users to view only subtasks matching a specific status.
|
||||
# Details:
|
||||
This task involves modifying the existing 'show' command functionality to support status-based filtering of subtasks. Implementation details include:
|
||||
|
||||
1. Update the command parser to accept a new '--status' or '-s' flag followed by a status value (e.g., 'task-master show --status=in-progress' or 'task-master show -s completed').
|
||||
|
||||
2. Modify the show command handler in the appropriate module (likely in scripts/modules/) to:
|
||||
- Parse and validate the status parameter
|
||||
- Filter the subtasks collection based on the provided status before displaying results
|
||||
- Handle invalid status values gracefully with appropriate error messages
|
||||
- Support standard status values (e.g., 'not-started', 'in-progress', 'completed', 'blocked')
|
||||
- Consider supporting multiple status values (comma-separated or multiple flags)
|
||||
|
||||
3. Update the help documentation to include information about the new status filtering option.
|
||||
|
||||
4. Ensure backward compatibility - the show command should function as before when no status parameter is provided.
|
||||
|
||||
5. Consider adding a '--status-list' option to display all available status values for reference.
|
||||
|
||||
6. Update any relevant unit tests to cover the new functionality.
|
||||
|
||||
7. If the application uses a database or persistent storage, ensure the filtering happens at the query level for performance when possible.
|
||||
|
||||
8. Maintain consistent formatting and styling of output regardless of filtering.
|
||||
|
||||
# Test Strategy:
|
||||
Testing for this feature should include:
|
||||
|
||||
1. Unit tests:
|
||||
- Test parsing of the status parameter in various formats (--status=value, -s value)
|
||||
- Test filtering logic with different status values
|
||||
- Test error handling for invalid status values
|
||||
- Test backward compatibility (no status parameter)
|
||||
- Test edge cases (empty status, case sensitivity, etc.)
|
||||
|
||||
2. Integration tests:
|
||||
- Verify that the command correctly filters subtasks when a valid status is provided
|
||||
- Verify that all subtasks are shown when no status filter is applied
|
||||
- Test with a project containing subtasks of various statuses
|
||||
|
||||
3. Manual testing:
|
||||
- Create a test project with multiple subtasks having different statuses
|
||||
- Run the show command with different status filters and verify results
|
||||
- Test with both long-form (--status) and short-form (-s) parameters
|
||||
- Verify help documentation correctly explains the new parameter
|
||||
|
||||
4. Edge case testing:
|
||||
- Test with non-existent status values
|
||||
- Test with empty project (no subtasks)
|
||||
- Test with a project where all subtasks have the same status
|
||||
|
||||
5. Documentation verification:
|
||||
- Ensure the README or help documentation is updated to include the new parameter
|
||||
- Verify examples in documentation work as expected
|
||||
|
||||
All tests should pass before considering this task complete.
|
||||
@@ -3421,7 +3421,7 @@
|
||||
"title": "Remove all unused imports",
|
||||
"description": "",
|
||||
"details": "",
|
||||
"status": "pending",
|
||||
"status": "done",
|
||||
"dependencies": [],
|
||||
"parentTaskId": 61
|
||||
},
|
||||
@@ -3442,6 +3442,15 @@
|
||||
"status": "pending",
|
||||
"dependencies": [],
|
||||
"parentTaskId": 61
|
||||
},
|
||||
{
|
||||
"id": 45,
|
||||
"title": "Add support for Bedrock provider with ai sdk and unified service",
|
||||
"description": "",
|
||||
"details": "\n\n<info added on 2025-04-25T19:03:42.584Z>\n- Install the Bedrock provider for the AI SDK using your package manager (e.g., npm i @ai-sdk/amazon-bedrock) and ensure the core AI SDK is present[3][4].\n\n- To integrate with your existing config manager, externalize all Bedrock-specific configuration (such as region, model name, and credential provider) into your config management system. For example, store values like region (\"us-east-1\") and model identifier (\"meta.llama3-8b-instruct-v1:0\") in your config files or environment variables, and load them at runtime.\n\n- For credentials, leverage the AWS SDK credential provider chain to avoid hardcoding secrets. Use the @aws-sdk/credential-providers package and pass a credentialProvider (e.g., fromNodeProviderChain()) to the Bedrock provider. This allows your config manager to control credential sourcing via environment, profiles, or IAM roles, consistent with other AWS integrations[1].\n\n- Example integration with config manager:\n ```js\n import { createAmazonBedrock } from '@ai-sdk/amazon-bedrock';\n import { fromNodeProviderChain } from '@aws-sdk/credential-providers';\n\n // Assume configManager.get returns your config values\n const region = configManager.get('bedrock.region');\n const model = configManager.get('bedrock.model');\n\n const bedrock = createAmazonBedrock({\n region,\n credentialProvider: fromNodeProviderChain(),\n });\n\n // Use with AI SDK methods\n const { text } = await generateText({\n model: bedrock(model),\n prompt: 'Your prompt here',\n });\n ```\n\n- If your config manager supports dynamic provider selection, you can abstract the provider initialization so switching between Bedrock and other providers (like OpenAI or Anthropic) is seamless.\n\n- Be aware that Bedrock exposes multiple models from different vendors, each with potentially different API behaviors. Your config should allow specifying the exact model string, and your integration should handle any model-specific options or response formats[5].\n\n- For unified service integration, ensure your service layer can route requests to Bedrock using the configured provider instance, and normalize responses if you support multiple AI backends.\n</info added on 2025-04-25T19:03:42.584Z>",
|
||||
"status": "pending",
|
||||
"dependencies": [],
|
||||
"parentTaskId": 61
|
||||
}
|
||||
]
|
||||
},
|
||||
@@ -3760,6 +3769,28 @@
|
||||
"testStrategy": "Perform a complete installation with Yarn and follow through any website account setup process. Compare the experience with npm installation to ensure identical behavior. Test edge cases such as account creation failures, login issues, and configuration changes. If no website or account setup is required, confirm and document this in the test results."
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": 65,
|
||||
"title": "Add Bun Support for Taskmaster Installation",
|
||||
"description": "Implement full support for installing and managing Taskmaster using the Bun package manager, ensuring the installation process and user experience are identical to npm, pnpm, and Yarn.",
|
||||
"details": "Update the Taskmaster installation scripts and documentation to support Bun as a first-class package manager. Ensure that users can install Taskmaster and run all CLI commands (including 'init' via scripts/init.js) using Bun, with the same directory structure, template copying, package.json merging, and MCP config setup as with npm, pnpm, and Yarn. Verify that all dependencies are compatible with Bun and that any Bun-specific configuration (such as lockfile handling or binary linking) is handled correctly. If the installation process includes a website or account setup, document and test these flows for parity; if not, explicitly confirm and document that no such steps are required. Update all relevant documentation and installation guides to include Bun instructions for macOS, Linux, and Windows (including WSL and PowerShell). Address any known Bun-specific issues (e.g., sporadic install hangs) with clear troubleshooting guidance.",
|
||||
"testStrategy": "1. Install Taskmaster using Bun on macOS, Linux, and Windows (including WSL and PowerShell), following the updated documentation. 2. Run the full installation and initialization process, verifying that the directory structure, templates, and MCP config are set up identically to npm, pnpm, and Yarn. 3. Execute all CLI commands (including 'init') and confirm functional parity. 4. If a website or account setup is required, test these flows for consistency; if not, confirm and document this. 5. Check for Bun-specific issues (e.g., install hangs) and verify that troubleshooting steps are effective. 6. Ensure the documentation is clear, accurate, and up to date for all supported platforms.",
|
||||
"status": "pending",
|
||||
"dependencies": [],
|
||||
"priority": "medium",
|
||||
"subtasks": []
|
||||
},
|
||||
{
|
||||
"id": 66,
|
||||
"title": "Support Status Filtering in Show Command for Subtasks",
|
||||
"description": "Enhance the 'show' command to accept a status parameter that filters subtasks by their current status, allowing users to view only subtasks matching a specific status.",
|
||||
"details": "This task involves modifying the existing 'show' command functionality to support status-based filtering of subtasks. Implementation details include:\n\n1. Update the command parser to accept a new '--status' or '-s' flag followed by a status value (e.g., 'task-master show --status=in-progress' or 'task-master show -s completed').\n\n2. Modify the show command handler in the appropriate module (likely in scripts/modules/) to:\n - Parse and validate the status parameter\n - Filter the subtasks collection based on the provided status before displaying results\n - Handle invalid status values gracefully with appropriate error messages\n - Support standard status values (e.g., 'not-started', 'in-progress', 'completed', 'blocked')\n - Consider supporting multiple status values (comma-separated or multiple flags)\n\n3. Update the help documentation to include information about the new status filtering option.\n\n4. Ensure backward compatibility - the show command should function as before when no status parameter is provided.\n\n5. Consider adding a '--status-list' option to display all available status values for reference.\n\n6. Update any relevant unit tests to cover the new functionality.\n\n7. If the application uses a database or persistent storage, ensure the filtering happens at the query level for performance when possible.\n\n8. Maintain consistent formatting and styling of output regardless of filtering.",
|
||||
"testStrategy": "Testing for this feature should include:\n\n1. Unit tests:\n - Test parsing of the status parameter in various formats (--status=value, -s value)\n - Test filtering logic with different status values\n - Test error handling for invalid status values\n - Test backward compatibility (no status parameter)\n - Test edge cases (empty status, case sensitivity, etc.)\n\n2. Integration tests:\n - Verify that the command correctly filters subtasks when a valid status is provided\n - Verify that all subtasks are shown when no status filter is applied\n - Test with a project containing subtasks of various statuses\n\n3. Manual testing:\n - Create a test project with multiple subtasks having different statuses\n - Run the show command with different status filters and verify results\n - Test with both long-form (--status) and short-form (-s) parameters\n - Verify help documentation correctly explains the new parameter\n\n4. Edge case testing:\n - Test with non-existent status values\n - Test with empty project (no subtasks)\n - Test with a project where all subtasks have the same status\n\n5. Documentation verification:\n - Ensure the README or help documentation is updated to include the new parameter\n - Verify examples in documentation work as expected\n\nAll tests should pass before considering this task complete.",
|
||||
"status": "pending",
|
||||
"dependencies": [],
|
||||
"priority": "medium",
|
||||
"subtasks": []
|
||||
}
|
||||
]
|
||||
}
|
||||
Reference in New Issue
Block a user