812 lines
24 KiB
JavaScript
Raw Normal View History

2025-03-31 17:09:31 +02:00
/**
* Task Master
* Copyright (c) 2025 Eyal Toledano, Ralph Khreish
*
* This software is licensed under the MIT License with Commons Clause.
* You may use this software for any purpose, including commercial applications,
* and modify and redistribute it freely, subject to the following restrictions:
*
* 1. You may not sell this software or offer it as a service.
* 2. The origin of this software must not be misrepresented.
* 3. Altered source versions must be plainly marked as such.
*
* For the full license text, see the LICENSE file in the root directory.
*/
import fs from 'fs';
import path from 'path';
import readline from 'readline';
import { fileURLToPath } from 'url';
import { dirname } from 'path';
2025-03-22 02:18:59 -04:00
import chalk from 'chalk';
import figlet from 'figlet';
import boxen from 'boxen';
import gradient from 'gradient-string';
import { isSilentMode } from './modules/utils.js';
🦘 Direct Integration of Roo Code Support (#285) * Direct Integration of Roo Code Support ## Overview This PR adds native Roo Code support directly within the Task Master package, in contrast to PR #279 which proposed using a separate repository and patch script approach. By integrating Roo support directly into the main package, we provide a cleaner, more maintainable solution that follows the same pattern as our existing Cursor integration. ## Key Changes 1. **Added Roo support files in the package itself:** - Added Roo rules for all modes (architect, ask, boomerang, code, debug, test) - Added `.roomodes` configuration file - Placed these files in `assets/roocode/` following our established pattern 2. **Enhanced init.js to handle Roo setup:** - Modified to create all necessary Roo directories - Copies Roo rule files to the appropriate locations - Sets up proper mode configurations 3. **Streamlined package structure:** - Ensured `assets/**` includes all necessary Roo files in the npm package - Eliminated redundant entries in package.json - Updated prepare-package.js to verify all required files 4. **Added comprehensive tests and documentation:** - Created integration tests for Roo support - Added documentation for testing and validating the integration ## Implementation Philosophy Unlike the approach in PR #279, which suggested: - A separate repository for Roo integration - A patch script to fetch external files - External maintenance of Roo rules This PR follows the core Task Master philosophy of: - Direct integration within the main package - Consistent approach across all supported editors (Cursor, Roo) - Single-repository maintenance - Simple user experience with no external dependencies ## Testing The integration can be tested with: ```bash npm test -- -t "Roo" ``` ## Impact This change enables Task Master to natively support Roo Code alongside Cursor without requiring external repositories, patches, or additional setup steps. Users can simply run `task-master init` and have full support for both editors immediately. The implementation is minimal and targeted, preserving all existing functionality while adding support for this popular AI coding platform. * Update roo-files-inclusion.test.js * Update README.md * Address PR feedback: move docs to contributor-docs, fix package.json references, regenerate package-lock.json @Crunchyman-ralph Thank you for the feedback! I've made the requested changes: 1. ✅ Moved testing-roo-integration.md to the contributor-docs folder 2. ✅ Removed manual package.json changes and used changeset instead 3. ✅ Fixed package references and regenerated package-lock.json 4. ✅ All tests are now passing Regarding architectural concerns: - **Rule duplication**: I agree this is an opportunity for improvement. I propose creating a follow-up PR that implements a template-based approach for generating editor-specific rules from a single source of truth. - **Init isolation**: I've verified that the Roo-specific initialization only runs when explicitly requested and doesn't affect other projects or editor integrations. - **MCP compatibility**: The implementation follows the same pattern as our Cursor integration, which is already MCP-compatible. I've tested this by [describe your testing approach here]. Let me know if you'd like any additional changes! * Address PR feedback: move docs to contributor-docs, fix package.json references, regenerate package-lock.json @Crunchyman-ralph Thank you for the feedback! I've made the requested changes: 1. ✅ Moved testing-roo-integration.md to the contributor-docs folder 2. ✅ Removed manual package.json changes and used changeset instead 3. ✅ Fixed package references and regenerated package-lock.json 4. ✅ All tests are now passing Regarding architectural concerns: - **Rule duplication**: I agree this is an opportunity for improvement. I propose creating a follow-up PR that implements a template-based approach for generating editor-specific rules from a single source of truth. - **Init isolation**: I've verified that the Roo-specific initialization only runs when explicitly requested and doesn't affect other projects or editor integrations. - **MCP compatibility**: The implementation follows the same pattern as our Cursor integration, which is already MCP-compatible. I've tested this by [describe your testing approach here]. Let me know if you'd like any additional changes! * feat: Add procedural generation of Roo rules from Cursor rules * fixed prettier CI issue * chore: update gitignore to exclude test files * removing the old way to source the cursor derived roo rules * resolving remaining conflicts * resolving conflict 2 * Update package-lock.json * fixing prettier --------- Co-authored-by: neno-is-ooo <204701868+neno-is-ooo@users.noreply.github.com>
2025-04-23 00:15:01 +02:00
import { convertAllCursorRulesToRooRules } from './modules/rule-transformer.js';
import { execSync } from 'child_process';
2025-05-31 16:21:03 +02:00
import {
EXAMPLE_PRD_FILE,
TASKMASTER_CONFIG_FILE,
TASKMASTER_TEMPLATES_DIR,
TASKMASTER_DIR,
TASKMASTER_TASKS_DIR,
TASKMASTER_DOCS_DIR,
TASKMASTER_REPORTS_DIR,
ENV_EXAMPLE_FILE,
GITIGNORE_FILE
} from '../src/constants/paths.js';
const __filename = fileURLToPath(import.meta.url);
const __dirname = dirname(__filename);
2025-03-04 13:55:17 -05:00
2025-03-22 02:18:59 -04:00
// Define log levels
2025-03-04 13:55:17 -05:00
const LOG_LEVELS = {
2025-04-09 00:25:27 +02:00
debug: 0,
info: 1,
warn: 2,
error: 3,
success: 4
2025-03-04 13:55:17 -05:00
};
// Determine log level from environment variable or default to 'info'
const LOG_LEVEL = process.env.TASKMASTER_LOG_LEVEL
? LOG_LEVELS[process.env.TASKMASTER_LOG_LEVEL.toLowerCase()]
: LOG_LEVELS.info; // Default to info
2025-03-04 13:55:17 -05:00
2025-03-22 02:18:59 -04:00
// Create a color gradient for the banner
const coolGradient = gradient(['#00b4d8', '#0077b6', '#03045e']);
const warmGradient = gradient(['#fb8b24', '#e36414', '#9a031e']);
// Display a fancy banner
function displayBanner() {
if (isSilentMode()) return;
2025-04-09 00:25:27 +02:00
console.clear();
const bannerText = figlet.textSync('Task Master AI', {
font: 'Standard',
horizontalLayout: 'default',
verticalLayout: 'default'
});
console.log(coolGradient(bannerText));
// Add creator credit line below the banner
console.log(
chalk.dim('by ') + chalk.cyan.underline('https://x.com/eyaltoledano')
);
console.log(
boxen(chalk.white(`${chalk.bold('Initializing')} your new project`), {
padding: 1,
margin: { top: 0, bottom: 1 },
borderStyle: 'round',
borderColor: 'cyan'
})
);
2025-03-22 02:18:59 -04:00
}
// Logging function with icons and colors
2025-03-04 13:55:17 -05:00
function log(level, ...args) {
2025-04-09 00:25:27 +02:00
const icons = {
debug: chalk.gray('🔍'),
info: chalk.blue(''),
warn: chalk.yellow('⚠️'),
error: chalk.red('❌'),
success: chalk.green('✅')
};
if (LOG_LEVELS[level] >= LOG_LEVEL) {
const icon = icons[level] || '';
// Only output to console if not in silent mode
if (!isSilentMode()) {
if (level === 'error') {
console.error(icon, chalk.red(...args));
} else if (level === 'warn') {
console.warn(icon, chalk.yellow(...args));
} else if (level === 'success') {
console.log(icon, chalk.green(...args));
} else if (level === 'info') {
console.log(icon, chalk.blue(...args));
} else {
console.log(icon, ...args);
}
2025-04-09 00:25:27 +02:00
}
}
// Write to debug log if DEBUG=true
if (process.env.DEBUG === 'true') {
const logMessage = `[${level.toUpperCase()}] ${args.join(' ')}\n`;
fs.appendFileSync('init-debug.log', logMessage);
}
2025-03-04 13:55:17 -05:00
}
// Function to create directory if it doesn't exist
function ensureDirectoryExists(dirPath) {
2025-04-09 00:25:27 +02:00
if (!fs.existsSync(dirPath)) {
fs.mkdirSync(dirPath, { recursive: true });
log('info', `Created directory: ${dirPath}`);
}
2025-03-04 13:55:17 -05:00
}
// Function to add shell aliases to the user's shell configuration
function addShellAliases() {
2025-04-09 00:25:27 +02:00
const homeDir = process.env.HOME || process.env.USERPROFILE;
let shellConfigFile;
// Determine which shell config file to use
if (process.env.SHELL?.includes('zsh')) {
shellConfigFile = path.join(homeDir, '.zshrc');
} else if (process.env.SHELL?.includes('bash')) {
shellConfigFile = path.join(homeDir, '.bashrc');
} else {
log('warn', 'Could not determine shell type. Aliases not added.');
return false;
}
try {
// Check if file exists
if (!fs.existsSync(shellConfigFile)) {
log(
'warn',
`Shell config file ${shellConfigFile} not found. Aliases not added.`
);
return false;
}
// Check if aliases already exist
const configContent = fs.readFileSync(shellConfigFile, 'utf8');
if (configContent.includes("alias tm='task-master'")) {
log('info', 'Task Master aliases already exist in shell config.');
return true;
}
// Add aliases to the shell config file
const aliasBlock = `
# Task Master aliases added on ${new Date().toLocaleDateString()}
alias tm='task-master'
alias taskmaster='task-master'
`;
2025-04-09 00:25:27 +02:00
fs.appendFileSync(shellConfigFile, aliasBlock);
log('success', `Added Task Master aliases to ${shellConfigFile}`);
log(
'info',
2025-05-31 16:21:03 +02:00
`To use the aliases in your current terminal, run: source ${shellConfigFile}`
2025-04-09 00:25:27 +02:00
);
return true;
} catch (error) {
log('error', `Failed to add aliases: ${error.message}`);
return false;
}
}
2025-03-04 13:55:17 -05:00
// Function to copy a file from the package to the target directory
function copyTemplateFile(templateName, targetPath, replacements = {}) {
2025-04-09 00:25:27 +02:00
// Get the file content from the appropriate source directory
let sourcePath;
// Map template names to their actual source paths
switch (templateName) {
// case 'scripts_README.md':
// sourcePath = path.join(__dirname, '..', 'assets', 'scripts_README.md');
// break;
2025-04-09 00:25:27 +02:00
case 'dev_workflow.mdc':
sourcePath = path.join(
__dirname,
'..',
'.cursor',
'rules',
'dev_workflow.mdc'
);
break;
case 'taskmaster.mdc':
sourcePath = path.join(
__dirname,
'..',
'.cursor',
'rules',
'taskmaster.mdc'
);
break;
case 'cursor_rules.mdc':
sourcePath = path.join(
__dirname,
'..',
'.cursor',
'rules',
'cursor_rules.mdc'
);
break;
case 'self_improve.mdc':
sourcePath = path.join(
__dirname,
'..',
'.cursor',
'rules',
'self_improve.mdc'
);
break;
// case 'README-task-master.md':
// sourcePath = path.join(__dirname, '..', 'README-task-master.md');
2025-04-09 00:25:27 +02:00
break;
case 'windsurfrules':
sourcePath = path.join(__dirname, '..', 'assets', '.windsurfrules');
break;
🦘 Direct Integration of Roo Code Support (#285) * Direct Integration of Roo Code Support ## Overview This PR adds native Roo Code support directly within the Task Master package, in contrast to PR #279 which proposed using a separate repository and patch script approach. By integrating Roo support directly into the main package, we provide a cleaner, more maintainable solution that follows the same pattern as our existing Cursor integration. ## Key Changes 1. **Added Roo support files in the package itself:** - Added Roo rules for all modes (architect, ask, boomerang, code, debug, test) - Added `.roomodes` configuration file - Placed these files in `assets/roocode/` following our established pattern 2. **Enhanced init.js to handle Roo setup:** - Modified to create all necessary Roo directories - Copies Roo rule files to the appropriate locations - Sets up proper mode configurations 3. **Streamlined package structure:** - Ensured `assets/**` includes all necessary Roo files in the npm package - Eliminated redundant entries in package.json - Updated prepare-package.js to verify all required files 4. **Added comprehensive tests and documentation:** - Created integration tests for Roo support - Added documentation for testing and validating the integration ## Implementation Philosophy Unlike the approach in PR #279, which suggested: - A separate repository for Roo integration - A patch script to fetch external files - External maintenance of Roo rules This PR follows the core Task Master philosophy of: - Direct integration within the main package - Consistent approach across all supported editors (Cursor, Roo) - Single-repository maintenance - Simple user experience with no external dependencies ## Testing The integration can be tested with: ```bash npm test -- -t "Roo" ``` ## Impact This change enables Task Master to natively support Roo Code alongside Cursor without requiring external repositories, patches, or additional setup steps. Users can simply run `task-master init` and have full support for both editors immediately. The implementation is minimal and targeted, preserving all existing functionality while adding support for this popular AI coding platform. * Update roo-files-inclusion.test.js * Update README.md * Address PR feedback: move docs to contributor-docs, fix package.json references, regenerate package-lock.json @Crunchyman-ralph Thank you for the feedback! I've made the requested changes: 1. ✅ Moved testing-roo-integration.md to the contributor-docs folder 2. ✅ Removed manual package.json changes and used changeset instead 3. ✅ Fixed package references and regenerated package-lock.json 4. ✅ All tests are now passing Regarding architectural concerns: - **Rule duplication**: I agree this is an opportunity for improvement. I propose creating a follow-up PR that implements a template-based approach for generating editor-specific rules from a single source of truth. - **Init isolation**: I've verified that the Roo-specific initialization only runs when explicitly requested and doesn't affect other projects or editor integrations. - **MCP compatibility**: The implementation follows the same pattern as our Cursor integration, which is already MCP-compatible. I've tested this by [describe your testing approach here]. Let me know if you'd like any additional changes! * Address PR feedback: move docs to contributor-docs, fix package.json references, regenerate package-lock.json @Crunchyman-ralph Thank you for the feedback! I've made the requested changes: 1. ✅ Moved testing-roo-integration.md to the contributor-docs folder 2. ✅ Removed manual package.json changes and used changeset instead 3. ✅ Fixed package references and regenerated package-lock.json 4. ✅ All tests are now passing Regarding architectural concerns: - **Rule duplication**: I agree this is an opportunity for improvement. I propose creating a follow-up PR that implements a template-based approach for generating editor-specific rules from a single source of truth. - **Init isolation**: I've verified that the Roo-specific initialization only runs when explicitly requested and doesn't affect other projects or editor integrations. - **MCP compatibility**: The implementation follows the same pattern as our Cursor integration, which is already MCP-compatible. I've tested this by [describe your testing approach here]. Let me know if you'd like any additional changes! * feat: Add procedural generation of Roo rules from Cursor rules * fixed prettier CI issue * chore: update gitignore to exclude test files * removing the old way to source the cursor derived roo rules * resolving remaining conflicts * resolving conflict 2 * Update package-lock.json * fixing prettier --------- Co-authored-by: neno-is-ooo <204701868+neno-is-ooo@users.noreply.github.com>
2025-04-23 00:15:01 +02:00
case '.roomodes':
sourcePath = path.join(__dirname, '..', 'assets', 'roocode', '.roomodes');
break;
case 'architect-rules':
case 'ask-rules':
case 'boomerang-rules':
case 'code-rules':
case 'debug-rules':
2025-05-31 16:21:03 +02:00
case 'test-rules': {
🦘 Direct Integration of Roo Code Support (#285) * Direct Integration of Roo Code Support ## Overview This PR adds native Roo Code support directly within the Task Master package, in contrast to PR #279 which proposed using a separate repository and patch script approach. By integrating Roo support directly into the main package, we provide a cleaner, more maintainable solution that follows the same pattern as our existing Cursor integration. ## Key Changes 1. **Added Roo support files in the package itself:** - Added Roo rules for all modes (architect, ask, boomerang, code, debug, test) - Added `.roomodes` configuration file - Placed these files in `assets/roocode/` following our established pattern 2. **Enhanced init.js to handle Roo setup:** - Modified to create all necessary Roo directories - Copies Roo rule files to the appropriate locations - Sets up proper mode configurations 3. **Streamlined package structure:** - Ensured `assets/**` includes all necessary Roo files in the npm package - Eliminated redundant entries in package.json - Updated prepare-package.js to verify all required files 4. **Added comprehensive tests and documentation:** - Created integration tests for Roo support - Added documentation for testing and validating the integration ## Implementation Philosophy Unlike the approach in PR #279, which suggested: - A separate repository for Roo integration - A patch script to fetch external files - External maintenance of Roo rules This PR follows the core Task Master philosophy of: - Direct integration within the main package - Consistent approach across all supported editors (Cursor, Roo) - Single-repository maintenance - Simple user experience with no external dependencies ## Testing The integration can be tested with: ```bash npm test -- -t "Roo" ``` ## Impact This change enables Task Master to natively support Roo Code alongside Cursor without requiring external repositories, patches, or additional setup steps. Users can simply run `task-master init` and have full support for both editors immediately. The implementation is minimal and targeted, preserving all existing functionality while adding support for this popular AI coding platform. * Update roo-files-inclusion.test.js * Update README.md * Address PR feedback: move docs to contributor-docs, fix package.json references, regenerate package-lock.json @Crunchyman-ralph Thank you for the feedback! I've made the requested changes: 1. ✅ Moved testing-roo-integration.md to the contributor-docs folder 2. ✅ Removed manual package.json changes and used changeset instead 3. ✅ Fixed package references and regenerated package-lock.json 4. ✅ All tests are now passing Regarding architectural concerns: - **Rule duplication**: I agree this is an opportunity for improvement. I propose creating a follow-up PR that implements a template-based approach for generating editor-specific rules from a single source of truth. - **Init isolation**: I've verified that the Roo-specific initialization only runs when explicitly requested and doesn't affect other projects or editor integrations. - **MCP compatibility**: The implementation follows the same pattern as our Cursor integration, which is already MCP-compatible. I've tested this by [describe your testing approach here]. Let me know if you'd like any additional changes! * Address PR feedback: move docs to contributor-docs, fix package.json references, regenerate package-lock.json @Crunchyman-ralph Thank you for the feedback! I've made the requested changes: 1. ✅ Moved testing-roo-integration.md to the contributor-docs folder 2. ✅ Removed manual package.json changes and used changeset instead 3. ✅ Fixed package references and regenerated package-lock.json 4. ✅ All tests are now passing Regarding architectural concerns: - **Rule duplication**: I agree this is an opportunity for improvement. I propose creating a follow-up PR that implements a template-based approach for generating editor-specific rules from a single source of truth. - **Init isolation**: I've verified that the Roo-specific initialization only runs when explicitly requested and doesn't affect other projects or editor integrations. - **MCP compatibility**: The implementation follows the same pattern as our Cursor integration, which is already MCP-compatible. I've tested this by [describe your testing approach here]. Let me know if you'd like any additional changes! * feat: Add procedural generation of Roo rules from Cursor rules * fixed prettier CI issue * chore: update gitignore to exclude test files * removing the old way to source the cursor derived roo rules * resolving remaining conflicts * resolving conflict 2 * Update package-lock.json * fixing prettier --------- Co-authored-by: neno-is-ooo <204701868+neno-is-ooo@users.noreply.github.com>
2025-04-23 00:15:01 +02:00
// Extract the mode name from the template name (e.g., 'architect' from 'architect-rules')
const mode = templateName.split('-')[0];
sourcePath = path.join(
__dirname,
'..',
'assets',
'roocode',
'.roo',
`rules-${mode}`,
templateName
);
break;
2025-05-31 16:21:03 +02:00
}
2025-04-09 00:25:27 +02:00
default:
// For other files like env.example, gitignore, etc. that don't have direct equivalents
sourcePath = path.join(__dirname, '..', 'assets', templateName);
}
// Check if the source file exists
if (!fs.existsSync(sourcePath)) {
// Fall back to templates directory for files that might not have been moved yet
sourcePath = path.join(__dirname, '..', 'assets', templateName);
if (!fs.existsSync(sourcePath)) {
log('error', `Source file not found: ${sourcePath}`);
return;
}
}
let content = fs.readFileSync(sourcePath, 'utf8');
// Replace placeholders with actual values
Object.entries(replacements).forEach(([key, value]) => {
const regex = new RegExp(`\\{\\{${key}\\}\\}`, 'g');
content = content.replace(regex, value);
});
// Handle special files that should be merged instead of overwritten
if (fs.existsSync(targetPath)) {
const filename = path.basename(targetPath);
// Handle .gitignore - append lines that don't exist
if (filename === '.gitignore') {
log('info', `${targetPath} already exists, merging content...`);
const existingContent = fs.readFileSync(targetPath, 'utf8');
const existingLines = new Set(
existingContent.split('\n').map((line) => line.trim())
);
const newLines = content
.split('\n')
.filter((line) => !existingLines.has(line.trim()));
if (newLines.length > 0) {
// Add a comment to separate the original content from our additions
const updatedContent = `${existingContent.trim()}\n\n# Added by Task Master AI\n${newLines.join('\n')}`;
2025-04-09 00:25:27 +02:00
fs.writeFileSync(targetPath, updatedContent);
log('success', `Updated ${targetPath} with additional entries`);
} else {
log('info', `No new content to add to ${targetPath}`);
}
return;
}
// Handle .windsurfrules - append the entire content
if (filename === '.windsurfrules') {
log(
'info',
`${targetPath} already exists, appending content instead of overwriting...`
);
const existingContent = fs.readFileSync(targetPath, 'utf8');
// Add a separator comment before appending our content
2025-05-31 16:21:03 +02:00
const updatedContent = `${existingContent.trim()}\n\n# Added by Task Master - Development Workflow Rules\n\n${content}`;
2025-04-09 00:25:27 +02:00
fs.writeFileSync(targetPath, updatedContent);
log('success', `Updated ${targetPath} with additional rules`);
return;
}
// Handle README.md - offer to preserve or create a different file
if (filename === 'README-task-master.md') {
2025-04-09 00:25:27 +02:00
log('info', `${targetPath} already exists`);
// Create a separate README file specifically for this project
const taskMasterReadmePath = path.join(
path.dirname(targetPath),
'README-task-master.md'
);
fs.writeFileSync(taskMasterReadmePath, content);
log(
'success',
`Created ${taskMasterReadmePath} (preserved original README-task-master.md)`
2025-04-09 00:25:27 +02:00
);
return;
}
// For other files, warn and prompt before overwriting
log('warn', `${targetPath} already exists, skipping.`);
2025-04-09 00:25:27 +02:00
return;
}
// If the file doesn't exist, create it normally
fs.writeFileSync(targetPath, content);
log('info', `Created file: ${targetPath}`);
2025-03-04 13:55:17 -05:00
}
// Main function to initialize a new project (No longer needs isInteractive logic)
async function initializeProject(options = {}) {
// Receives options as argument
// Only display banner if not in silent mode
if (!isSilentMode()) {
displayBanner();
}
2025-04-09 00:25:27 +02:00
// Debug logging only if not in silent mode
// if (!isSilentMode()) {
// console.log('===== DEBUG: INITIALIZE PROJECT OPTIONS RECEIVED =====');
// console.log('Full options object:', JSON.stringify(options));
// console.log('options.yes:', options.yes);
// console.log('==================================================');
// }
const skipPrompts = options.yes || (options.name && options.description);
// if (!isSilentMode()) {
// console.log('Skip prompts determined:', skipPrompts);
// }
if (skipPrompts) {
if (!isSilentMode()) {
console.log('SKIPPING PROMPTS - Using defaults or provided values');
}
// Use provided options or defaults
const projectName = options.name || 'task-master-project';
const projectDescription =
options.description || 'A project managed with Task Master AI';
const projectVersion = options.version || '0.1.0';
const authorName = options.author || 'Vibe coder';
2025-04-09 00:25:27 +02:00
const dryRun = options.dryRun || false;
const addAliases = options.aliases || false;
2025-04-09 00:25:27 +02:00
if (dryRun) {
log('info', 'DRY RUN MODE: No files will be modified');
log('info', 'Would initialize Task Master project');
2025-04-09 00:25:27 +02:00
log('info', 'Would create/update necessary project files');
if (addAliases) {
log('info', 'Would add shell aliases for task-master');
}
return {
dryRun: true
};
}
2025-05-31 16:21:03 +02:00
createProjectStructure(addAliases, dryRun, options);
} else {
// Interactive logic
log('info', 'Required options not provided, proceeding with prompts.');
const rl = readline.createInterface({
input: process.stdin,
output: process.stdout
});
2025-04-09 00:25:27 +02:00
try {
// Only prompt for shell aliases
const addAliasesInput = await promptQuestion(
rl,
chalk.cyan(
'Add shell aliases for task-master? This lets you type "tm" instead of "task-master" (Y/n): '
)
);
const addAliasesPrompted = addAliasesInput.trim().toLowerCase() !== 'n';
// Confirm settings...
console.log('\nTask Master Project settings:');
console.log(
chalk.blue(
'Add shell aliases (so you can use "tm" instead of "task-master"):'
),
chalk.white(addAliasesPrompted ? 'Yes' : 'No')
);
2025-04-09 00:25:27 +02:00
const confirmInput = await promptQuestion(
rl,
chalk.yellow('\nDo you want to continue with these settings? (Y/n): ')
);
const shouldContinue = confirmInput.trim().toLowerCase() !== 'n';
rl.close();
2025-04-09 00:25:27 +02:00
if (!shouldContinue) {
log('info', 'Project initialization cancelled by user');
process.exit(0);
return;
2025-04-09 00:25:27 +02:00
}
const dryRun = options.dryRun || false;
if (dryRun) {
log('info', 'DRY RUN MODE: No files will be modified');
log('info', 'Would initialize Task Master project');
log('info', 'Would create/update necessary project files');
if (addAliasesPrompted) {
log('info', 'Would add shell aliases for task-master');
}
return {
dryRun: true
};
2025-04-09 00:25:27 +02:00
}
// Create structure using only necessary values
2025-05-31 16:21:03 +02:00
createProjectStructure(addAliasesPrompted, dryRun, options);
} catch (error) {
rl.close();
log('error', `Error during initialization process: ${error.message}`);
process.exit(1);
}
2025-04-09 00:25:27 +02:00
}
}
// Helper function to promisify readline question
function promptQuestion(rl, question) {
2025-04-09 00:25:27 +02:00
return new Promise((resolve) => {
rl.question(question, (answer) => {
resolve(answer);
});
});
2025-03-04 13:55:17 -05:00
}
// Function to create the project structure
2025-05-31 16:21:03 +02:00
function createProjectStructure(addAliases, dryRun, options) {
2025-04-09 00:25:27 +02:00
const targetDir = process.cwd();
log('info', `Initializing project in ${targetDir}`);
2025-05-31 16:21:03 +02:00
// Define Roo modes locally (external integration, not part of core Task Master)
const ROO_MODES = ['architect', 'ask', 'boomerang', 'code', 'debug', 'test'];
2025-04-09 00:25:27 +02:00
// Create directories
2025-05-31 16:21:03 +02:00
ensureDirectoryExists(path.join(targetDir, '.cursor/rules'));
2025-04-09 00:25:27 +02:00
🦘 Direct Integration of Roo Code Support (#285) * Direct Integration of Roo Code Support ## Overview This PR adds native Roo Code support directly within the Task Master package, in contrast to PR #279 which proposed using a separate repository and patch script approach. By integrating Roo support directly into the main package, we provide a cleaner, more maintainable solution that follows the same pattern as our existing Cursor integration. ## Key Changes 1. **Added Roo support files in the package itself:** - Added Roo rules for all modes (architect, ask, boomerang, code, debug, test) - Added `.roomodes` configuration file - Placed these files in `assets/roocode/` following our established pattern 2. **Enhanced init.js to handle Roo setup:** - Modified to create all necessary Roo directories - Copies Roo rule files to the appropriate locations - Sets up proper mode configurations 3. **Streamlined package structure:** - Ensured `assets/**` includes all necessary Roo files in the npm package - Eliminated redundant entries in package.json - Updated prepare-package.js to verify all required files 4. **Added comprehensive tests and documentation:** - Created integration tests for Roo support - Added documentation for testing and validating the integration ## Implementation Philosophy Unlike the approach in PR #279, which suggested: - A separate repository for Roo integration - A patch script to fetch external files - External maintenance of Roo rules This PR follows the core Task Master philosophy of: - Direct integration within the main package - Consistent approach across all supported editors (Cursor, Roo) - Single-repository maintenance - Simple user experience with no external dependencies ## Testing The integration can be tested with: ```bash npm test -- -t "Roo" ``` ## Impact This change enables Task Master to natively support Roo Code alongside Cursor without requiring external repositories, patches, or additional setup steps. Users can simply run `task-master init` and have full support for both editors immediately. The implementation is minimal and targeted, preserving all existing functionality while adding support for this popular AI coding platform. * Update roo-files-inclusion.test.js * Update README.md * Address PR feedback: move docs to contributor-docs, fix package.json references, regenerate package-lock.json @Crunchyman-ralph Thank you for the feedback! I've made the requested changes: 1. ✅ Moved testing-roo-integration.md to the contributor-docs folder 2. ✅ Removed manual package.json changes and used changeset instead 3. ✅ Fixed package references and regenerated package-lock.json 4. ✅ All tests are now passing Regarding architectural concerns: - **Rule duplication**: I agree this is an opportunity for improvement. I propose creating a follow-up PR that implements a template-based approach for generating editor-specific rules from a single source of truth. - **Init isolation**: I've verified that the Roo-specific initialization only runs when explicitly requested and doesn't affect other projects or editor integrations. - **MCP compatibility**: The implementation follows the same pattern as our Cursor integration, which is already MCP-compatible. I've tested this by [describe your testing approach here]. Let me know if you'd like any additional changes! * Address PR feedback: move docs to contributor-docs, fix package.json references, regenerate package-lock.json @Crunchyman-ralph Thank you for the feedback! I've made the requested changes: 1. ✅ Moved testing-roo-integration.md to the contributor-docs folder 2. ✅ Removed manual package.json changes and used changeset instead 3. ✅ Fixed package references and regenerated package-lock.json 4. ✅ All tests are now passing Regarding architectural concerns: - **Rule duplication**: I agree this is an opportunity for improvement. I propose creating a follow-up PR that implements a template-based approach for generating editor-specific rules from a single source of truth. - **Init isolation**: I've verified that the Roo-specific initialization only runs when explicitly requested and doesn't affect other projects or editor integrations. - **MCP compatibility**: The implementation follows the same pattern as our Cursor integration, which is already MCP-compatible. I've tested this by [describe your testing approach here]. Let me know if you'd like any additional changes! * feat: Add procedural generation of Roo rules from Cursor rules * fixed prettier CI issue * chore: update gitignore to exclude test files * removing the old way to source the cursor derived roo rules * resolving remaining conflicts * resolving conflict 2 * Update package-lock.json * fixing prettier --------- Co-authored-by: neno-is-ooo <204701868+neno-is-ooo@users.noreply.github.com>
2025-04-23 00:15:01 +02:00
// Create Roo directories
ensureDirectoryExists(path.join(targetDir, '.roo'));
2025-05-31 16:21:03 +02:00
ensureDirectoryExists(path.join(targetDir, '.roo/rules'));
for (const mode of ROO_MODES) {
🦘 Direct Integration of Roo Code Support (#285) * Direct Integration of Roo Code Support ## Overview This PR adds native Roo Code support directly within the Task Master package, in contrast to PR #279 which proposed using a separate repository and patch script approach. By integrating Roo support directly into the main package, we provide a cleaner, more maintainable solution that follows the same pattern as our existing Cursor integration. ## Key Changes 1. **Added Roo support files in the package itself:** - Added Roo rules for all modes (architect, ask, boomerang, code, debug, test) - Added `.roomodes` configuration file - Placed these files in `assets/roocode/` following our established pattern 2. **Enhanced init.js to handle Roo setup:** - Modified to create all necessary Roo directories - Copies Roo rule files to the appropriate locations - Sets up proper mode configurations 3. **Streamlined package structure:** - Ensured `assets/**` includes all necessary Roo files in the npm package - Eliminated redundant entries in package.json - Updated prepare-package.js to verify all required files 4. **Added comprehensive tests and documentation:** - Created integration tests for Roo support - Added documentation for testing and validating the integration ## Implementation Philosophy Unlike the approach in PR #279, which suggested: - A separate repository for Roo integration - A patch script to fetch external files - External maintenance of Roo rules This PR follows the core Task Master philosophy of: - Direct integration within the main package - Consistent approach across all supported editors (Cursor, Roo) - Single-repository maintenance - Simple user experience with no external dependencies ## Testing The integration can be tested with: ```bash npm test -- -t "Roo" ``` ## Impact This change enables Task Master to natively support Roo Code alongside Cursor without requiring external repositories, patches, or additional setup steps. Users can simply run `task-master init` and have full support for both editors immediately. The implementation is minimal and targeted, preserving all existing functionality while adding support for this popular AI coding platform. * Update roo-files-inclusion.test.js * Update README.md * Address PR feedback: move docs to contributor-docs, fix package.json references, regenerate package-lock.json @Crunchyman-ralph Thank you for the feedback! I've made the requested changes: 1. ✅ Moved testing-roo-integration.md to the contributor-docs folder 2. ✅ Removed manual package.json changes and used changeset instead 3. ✅ Fixed package references and regenerated package-lock.json 4. ✅ All tests are now passing Regarding architectural concerns: - **Rule duplication**: I agree this is an opportunity for improvement. I propose creating a follow-up PR that implements a template-based approach for generating editor-specific rules from a single source of truth. - **Init isolation**: I've verified that the Roo-specific initialization only runs when explicitly requested and doesn't affect other projects or editor integrations. - **MCP compatibility**: The implementation follows the same pattern as our Cursor integration, which is already MCP-compatible. I've tested this by [describe your testing approach here]. Let me know if you'd like any additional changes! * Address PR feedback: move docs to contributor-docs, fix package.json references, regenerate package-lock.json @Crunchyman-ralph Thank you for the feedback! I've made the requested changes: 1. ✅ Moved testing-roo-integration.md to the contributor-docs folder 2. ✅ Removed manual package.json changes and used changeset instead 3. ✅ Fixed package references and regenerated package-lock.json 4. ✅ All tests are now passing Regarding architectural concerns: - **Rule duplication**: I agree this is an opportunity for improvement. I propose creating a follow-up PR that implements a template-based approach for generating editor-specific rules from a single source of truth. - **Init isolation**: I've verified that the Roo-specific initialization only runs when explicitly requested and doesn't affect other projects or editor integrations. - **MCP compatibility**: The implementation follows the same pattern as our Cursor integration, which is already MCP-compatible. I've tested this by [describe your testing approach here]. Let me know if you'd like any additional changes! * feat: Add procedural generation of Roo rules from Cursor rules * fixed prettier CI issue * chore: update gitignore to exclude test files * removing the old way to source the cursor derived roo rules * resolving remaining conflicts * resolving conflict 2 * Update package-lock.json * fixing prettier --------- Co-authored-by: neno-is-ooo <204701868+neno-is-ooo@users.noreply.github.com>
2025-04-23 00:15:01 +02:00
ensureDirectoryExists(path.join(targetDir, '.roo', `rules-${mode}`));
2025-04-09 00:25:27 +02:00
}
2025-05-31 16:21:03 +02:00
// Create NEW .taskmaster directory structure (using constants)
ensureDirectoryExists(path.join(targetDir, TASKMASTER_DIR));
ensureDirectoryExists(path.join(targetDir, TASKMASTER_TASKS_DIR));
ensureDirectoryExists(path.join(targetDir, TASKMASTER_DOCS_DIR));
ensureDirectoryExists(path.join(targetDir, TASKMASTER_REPORTS_DIR));
ensureDirectoryExists(path.join(targetDir, TASKMASTER_TEMPLATES_DIR));
2025-04-09 00:25:27 +02:00
// Setup MCP configuration for integration with Cursor
setupMCPConfiguration(targetDir);
2025-04-09 00:25:27 +02:00
// Copy template files with replacements
const replacements = {
year: new Date().getFullYear()
};
// Copy .env.example
copyTemplateFile(
'env.example',
2025-05-31 16:21:03 +02:00
path.join(targetDir, ENV_EXAMPLE_FILE),
2025-04-09 00:25:27 +02:00
replacements
);
// Copy config.json with project name to NEW location
copyTemplateFile(
'config.json',
2025-05-31 16:21:03 +02:00
path.join(targetDir, TASKMASTER_CONFIG_FILE),
{
...replacements
}
);
2025-04-09 00:25:27 +02:00
// Copy .gitignore
2025-05-31 16:21:03 +02:00
copyTemplateFile('gitignore', path.join(targetDir, GITIGNORE_FILE));
2025-04-09 00:25:27 +02:00
// Copy dev_workflow.mdc
copyTemplateFile(
'dev_workflow.mdc',
2025-05-31 16:21:03 +02:00
path.join(targetDir, '.cursor/rules/dev_workflow.mdc')
2025-04-09 00:25:27 +02:00
);
// Copy taskmaster.mdc
copyTemplateFile(
'taskmaster.mdc',
2025-05-31 16:21:03 +02:00
path.join(targetDir, '.cursor/rules/taskmaster.mdc')
2025-04-09 00:25:27 +02:00
);
// Copy cursor_rules.mdc
copyTemplateFile(
'cursor_rules.mdc',
2025-05-31 16:21:03 +02:00
path.join(targetDir, '.cursor/rules/cursor_rules.mdc')
2025-04-09 00:25:27 +02:00
);
// Copy self_improve.mdc
copyTemplateFile(
'self_improve.mdc',
2025-05-31 16:21:03 +02:00
path.join(targetDir, '.cursor/rules/self_improve.mdc')
2025-04-09 00:25:27 +02:00
);
🦘 Direct Integration of Roo Code Support (#285) * Direct Integration of Roo Code Support ## Overview This PR adds native Roo Code support directly within the Task Master package, in contrast to PR #279 which proposed using a separate repository and patch script approach. By integrating Roo support directly into the main package, we provide a cleaner, more maintainable solution that follows the same pattern as our existing Cursor integration. ## Key Changes 1. **Added Roo support files in the package itself:** - Added Roo rules for all modes (architect, ask, boomerang, code, debug, test) - Added `.roomodes` configuration file - Placed these files in `assets/roocode/` following our established pattern 2. **Enhanced init.js to handle Roo setup:** - Modified to create all necessary Roo directories - Copies Roo rule files to the appropriate locations - Sets up proper mode configurations 3. **Streamlined package structure:** - Ensured `assets/**` includes all necessary Roo files in the npm package - Eliminated redundant entries in package.json - Updated prepare-package.js to verify all required files 4. **Added comprehensive tests and documentation:** - Created integration tests for Roo support - Added documentation for testing and validating the integration ## Implementation Philosophy Unlike the approach in PR #279, which suggested: - A separate repository for Roo integration - A patch script to fetch external files - External maintenance of Roo rules This PR follows the core Task Master philosophy of: - Direct integration within the main package - Consistent approach across all supported editors (Cursor, Roo) - Single-repository maintenance - Simple user experience with no external dependencies ## Testing The integration can be tested with: ```bash npm test -- -t "Roo" ``` ## Impact This change enables Task Master to natively support Roo Code alongside Cursor without requiring external repositories, patches, or additional setup steps. Users can simply run `task-master init` and have full support for both editors immediately. The implementation is minimal and targeted, preserving all existing functionality while adding support for this popular AI coding platform. * Update roo-files-inclusion.test.js * Update README.md * Address PR feedback: move docs to contributor-docs, fix package.json references, regenerate package-lock.json @Crunchyman-ralph Thank you for the feedback! I've made the requested changes: 1. ✅ Moved testing-roo-integration.md to the contributor-docs folder 2. ✅ Removed manual package.json changes and used changeset instead 3. ✅ Fixed package references and regenerated package-lock.json 4. ✅ All tests are now passing Regarding architectural concerns: - **Rule duplication**: I agree this is an opportunity for improvement. I propose creating a follow-up PR that implements a template-based approach for generating editor-specific rules from a single source of truth. - **Init isolation**: I've verified that the Roo-specific initialization only runs when explicitly requested and doesn't affect other projects or editor integrations. - **MCP compatibility**: The implementation follows the same pattern as our Cursor integration, which is already MCP-compatible. I've tested this by [describe your testing approach here]. Let me know if you'd like any additional changes! * Address PR feedback: move docs to contributor-docs, fix package.json references, regenerate package-lock.json @Crunchyman-ralph Thank you for the feedback! I've made the requested changes: 1. ✅ Moved testing-roo-integration.md to the contributor-docs folder 2. ✅ Removed manual package.json changes and used changeset instead 3. ✅ Fixed package references and regenerated package-lock.json 4. ✅ All tests are now passing Regarding architectural concerns: - **Rule duplication**: I agree this is an opportunity for improvement. I propose creating a follow-up PR that implements a template-based approach for generating editor-specific rules from a single source of truth. - **Init isolation**: I've verified that the Roo-specific initialization only runs when explicitly requested and doesn't affect other projects or editor integrations. - **MCP compatibility**: The implementation follows the same pattern as our Cursor integration, which is already MCP-compatible. I've tested this by [describe your testing approach here]. Let me know if you'd like any additional changes! * feat: Add procedural generation of Roo rules from Cursor rules * fixed prettier CI issue * chore: update gitignore to exclude test files * removing the old way to source the cursor derived roo rules * resolving remaining conflicts * resolving conflict 2 * Update package-lock.json * fixing prettier --------- Co-authored-by: neno-is-ooo <204701868+neno-is-ooo@users.noreply.github.com>
2025-04-23 00:15:01 +02:00
// Generate Roo rules from Cursor rules
log('info', 'Generating Roo rules from Cursor rules...');
convertAllCursorRulesToRooRules(targetDir);
2025-04-09 00:25:27 +02:00
// Copy .windsurfrules
copyTemplateFile('windsurfrules', path.join(targetDir, '.windsurfrules'));
🦘 Direct Integration of Roo Code Support (#285) * Direct Integration of Roo Code Support ## Overview This PR adds native Roo Code support directly within the Task Master package, in contrast to PR #279 which proposed using a separate repository and patch script approach. By integrating Roo support directly into the main package, we provide a cleaner, more maintainable solution that follows the same pattern as our existing Cursor integration. ## Key Changes 1. **Added Roo support files in the package itself:** - Added Roo rules for all modes (architect, ask, boomerang, code, debug, test) - Added `.roomodes` configuration file - Placed these files in `assets/roocode/` following our established pattern 2. **Enhanced init.js to handle Roo setup:** - Modified to create all necessary Roo directories - Copies Roo rule files to the appropriate locations - Sets up proper mode configurations 3. **Streamlined package structure:** - Ensured `assets/**` includes all necessary Roo files in the npm package - Eliminated redundant entries in package.json - Updated prepare-package.js to verify all required files 4. **Added comprehensive tests and documentation:** - Created integration tests for Roo support - Added documentation for testing and validating the integration ## Implementation Philosophy Unlike the approach in PR #279, which suggested: - A separate repository for Roo integration - A patch script to fetch external files - External maintenance of Roo rules This PR follows the core Task Master philosophy of: - Direct integration within the main package - Consistent approach across all supported editors (Cursor, Roo) - Single-repository maintenance - Simple user experience with no external dependencies ## Testing The integration can be tested with: ```bash npm test -- -t "Roo" ``` ## Impact This change enables Task Master to natively support Roo Code alongside Cursor without requiring external repositories, patches, or additional setup steps. Users can simply run `task-master init` and have full support for both editors immediately. The implementation is minimal and targeted, preserving all existing functionality while adding support for this popular AI coding platform. * Update roo-files-inclusion.test.js * Update README.md * Address PR feedback: move docs to contributor-docs, fix package.json references, regenerate package-lock.json @Crunchyman-ralph Thank you for the feedback! I've made the requested changes: 1. ✅ Moved testing-roo-integration.md to the contributor-docs folder 2. ✅ Removed manual package.json changes and used changeset instead 3. ✅ Fixed package references and regenerated package-lock.json 4. ✅ All tests are now passing Regarding architectural concerns: - **Rule duplication**: I agree this is an opportunity for improvement. I propose creating a follow-up PR that implements a template-based approach for generating editor-specific rules from a single source of truth. - **Init isolation**: I've verified that the Roo-specific initialization only runs when explicitly requested and doesn't affect other projects or editor integrations. - **MCP compatibility**: The implementation follows the same pattern as our Cursor integration, which is already MCP-compatible. I've tested this by [describe your testing approach here]. Let me know if you'd like any additional changes! * Address PR feedback: move docs to contributor-docs, fix package.json references, regenerate package-lock.json @Crunchyman-ralph Thank you for the feedback! I've made the requested changes: 1. ✅ Moved testing-roo-integration.md to the contributor-docs folder 2. ✅ Removed manual package.json changes and used changeset instead 3. ✅ Fixed package references and regenerated package-lock.json 4. ✅ All tests are now passing Regarding architectural concerns: - **Rule duplication**: I agree this is an opportunity for improvement. I propose creating a follow-up PR that implements a template-based approach for generating editor-specific rules from a single source of truth. - **Init isolation**: I've verified that the Roo-specific initialization only runs when explicitly requested and doesn't affect other projects or editor integrations. - **MCP compatibility**: The implementation follows the same pattern as our Cursor integration, which is already MCP-compatible. I've tested this by [describe your testing approach here]. Let me know if you'd like any additional changes! * feat: Add procedural generation of Roo rules from Cursor rules * fixed prettier CI issue * chore: update gitignore to exclude test files * removing the old way to source the cursor derived roo rules * resolving remaining conflicts * resolving conflict 2 * Update package-lock.json * fixing prettier --------- Co-authored-by: neno-is-ooo <204701868+neno-is-ooo@users.noreply.github.com>
2025-04-23 00:15:01 +02:00
// Copy .roomodes for Roo Code integration
copyTemplateFile('.roomodes', path.join(targetDir, '.roomodes'));
2025-04-09 00:25:27 +02:00
🦘 Direct Integration of Roo Code Support (#285) * Direct Integration of Roo Code Support ## Overview This PR adds native Roo Code support directly within the Task Master package, in contrast to PR #279 which proposed using a separate repository and patch script approach. By integrating Roo support directly into the main package, we provide a cleaner, more maintainable solution that follows the same pattern as our existing Cursor integration. ## Key Changes 1. **Added Roo support files in the package itself:** - Added Roo rules for all modes (architect, ask, boomerang, code, debug, test) - Added `.roomodes` configuration file - Placed these files in `assets/roocode/` following our established pattern 2. **Enhanced init.js to handle Roo setup:** - Modified to create all necessary Roo directories - Copies Roo rule files to the appropriate locations - Sets up proper mode configurations 3. **Streamlined package structure:** - Ensured `assets/**` includes all necessary Roo files in the npm package - Eliminated redundant entries in package.json - Updated prepare-package.js to verify all required files 4. **Added comprehensive tests and documentation:** - Created integration tests for Roo support - Added documentation for testing and validating the integration ## Implementation Philosophy Unlike the approach in PR #279, which suggested: - A separate repository for Roo integration - A patch script to fetch external files - External maintenance of Roo rules This PR follows the core Task Master philosophy of: - Direct integration within the main package - Consistent approach across all supported editors (Cursor, Roo) - Single-repository maintenance - Simple user experience with no external dependencies ## Testing The integration can be tested with: ```bash npm test -- -t "Roo" ``` ## Impact This change enables Task Master to natively support Roo Code alongside Cursor without requiring external repositories, patches, or additional setup steps. Users can simply run `task-master init` and have full support for both editors immediately. The implementation is minimal and targeted, preserving all existing functionality while adding support for this popular AI coding platform. * Update roo-files-inclusion.test.js * Update README.md * Address PR feedback: move docs to contributor-docs, fix package.json references, regenerate package-lock.json @Crunchyman-ralph Thank you for the feedback! I've made the requested changes: 1. ✅ Moved testing-roo-integration.md to the contributor-docs folder 2. ✅ Removed manual package.json changes and used changeset instead 3. ✅ Fixed package references and regenerated package-lock.json 4. ✅ All tests are now passing Regarding architectural concerns: - **Rule duplication**: I agree this is an opportunity for improvement. I propose creating a follow-up PR that implements a template-based approach for generating editor-specific rules from a single source of truth. - **Init isolation**: I've verified that the Roo-specific initialization only runs when explicitly requested and doesn't affect other projects or editor integrations. - **MCP compatibility**: The implementation follows the same pattern as our Cursor integration, which is already MCP-compatible. I've tested this by [describe your testing approach here]. Let me know if you'd like any additional changes! * Address PR feedback: move docs to contributor-docs, fix package.json references, regenerate package-lock.json @Crunchyman-ralph Thank you for the feedback! I've made the requested changes: 1. ✅ Moved testing-roo-integration.md to the contributor-docs folder 2. ✅ Removed manual package.json changes and used changeset instead 3. ✅ Fixed package references and regenerated package-lock.json 4. ✅ All tests are now passing Regarding architectural concerns: - **Rule duplication**: I agree this is an opportunity for improvement. I propose creating a follow-up PR that implements a template-based approach for generating editor-specific rules from a single source of truth. - **Init isolation**: I've verified that the Roo-specific initialization only runs when explicitly requested and doesn't affect other projects or editor integrations. - **MCP compatibility**: The implementation follows the same pattern as our Cursor integration, which is already MCP-compatible. I've tested this by [describe your testing approach here]. Let me know if you'd like any additional changes! * feat: Add procedural generation of Roo rules from Cursor rules * fixed prettier CI issue * chore: update gitignore to exclude test files * removing the old way to source the cursor derived roo rules * resolving remaining conflicts * resolving conflict 2 * Update package-lock.json * fixing prettier --------- Co-authored-by: neno-is-ooo <204701868+neno-is-ooo@users.noreply.github.com>
2025-04-23 00:15:01 +02:00
// Copy Roo rule files for each mode
2025-05-31 16:21:03 +02:00
for (const mode of ROO_MODES) {
🦘 Direct Integration of Roo Code Support (#285) * Direct Integration of Roo Code Support ## Overview This PR adds native Roo Code support directly within the Task Master package, in contrast to PR #279 which proposed using a separate repository and patch script approach. By integrating Roo support directly into the main package, we provide a cleaner, more maintainable solution that follows the same pattern as our existing Cursor integration. ## Key Changes 1. **Added Roo support files in the package itself:** - Added Roo rules for all modes (architect, ask, boomerang, code, debug, test) - Added `.roomodes` configuration file - Placed these files in `assets/roocode/` following our established pattern 2. **Enhanced init.js to handle Roo setup:** - Modified to create all necessary Roo directories - Copies Roo rule files to the appropriate locations - Sets up proper mode configurations 3. **Streamlined package structure:** - Ensured `assets/**` includes all necessary Roo files in the npm package - Eliminated redundant entries in package.json - Updated prepare-package.js to verify all required files 4. **Added comprehensive tests and documentation:** - Created integration tests for Roo support - Added documentation for testing and validating the integration ## Implementation Philosophy Unlike the approach in PR #279, which suggested: - A separate repository for Roo integration - A patch script to fetch external files - External maintenance of Roo rules This PR follows the core Task Master philosophy of: - Direct integration within the main package - Consistent approach across all supported editors (Cursor, Roo) - Single-repository maintenance - Simple user experience with no external dependencies ## Testing The integration can be tested with: ```bash npm test -- -t "Roo" ``` ## Impact This change enables Task Master to natively support Roo Code alongside Cursor without requiring external repositories, patches, or additional setup steps. Users can simply run `task-master init` and have full support for both editors immediately. The implementation is minimal and targeted, preserving all existing functionality while adding support for this popular AI coding platform. * Update roo-files-inclusion.test.js * Update README.md * Address PR feedback: move docs to contributor-docs, fix package.json references, regenerate package-lock.json @Crunchyman-ralph Thank you for the feedback! I've made the requested changes: 1. ✅ Moved testing-roo-integration.md to the contributor-docs folder 2. ✅ Removed manual package.json changes and used changeset instead 3. ✅ Fixed package references and regenerated package-lock.json 4. ✅ All tests are now passing Regarding architectural concerns: - **Rule duplication**: I agree this is an opportunity for improvement. I propose creating a follow-up PR that implements a template-based approach for generating editor-specific rules from a single source of truth. - **Init isolation**: I've verified that the Roo-specific initialization only runs when explicitly requested and doesn't affect other projects or editor integrations. - **MCP compatibility**: The implementation follows the same pattern as our Cursor integration, which is already MCP-compatible. I've tested this by [describe your testing approach here]. Let me know if you'd like any additional changes! * Address PR feedback: move docs to contributor-docs, fix package.json references, regenerate package-lock.json @Crunchyman-ralph Thank you for the feedback! I've made the requested changes: 1. ✅ Moved testing-roo-integration.md to the contributor-docs folder 2. ✅ Removed manual package.json changes and used changeset instead 3. ✅ Fixed package references and regenerated package-lock.json 4. ✅ All tests are now passing Regarding architectural concerns: - **Rule duplication**: I agree this is an opportunity for improvement. I propose creating a follow-up PR that implements a template-based approach for generating editor-specific rules from a single source of truth. - **Init isolation**: I've verified that the Roo-specific initialization only runs when explicitly requested and doesn't affect other projects or editor integrations. - **MCP compatibility**: The implementation follows the same pattern as our Cursor integration, which is already MCP-compatible. I've tested this by [describe your testing approach here]. Let me know if you'd like any additional changes! * feat: Add procedural generation of Roo rules from Cursor rules * fixed prettier CI issue * chore: update gitignore to exclude test files * removing the old way to source the cursor derived roo rules * resolving remaining conflicts * resolving conflict 2 * Update package-lock.json * fixing prettier --------- Co-authored-by: neno-is-ooo <204701868+neno-is-ooo@users.noreply.github.com>
2025-04-23 00:15:01 +02:00
copyTemplateFile(
`${mode}-rules`,
path.join(targetDir, '.roo', `rules-${mode}`, `${mode}-rules`)
);
}
2025-04-09 00:25:27 +02:00
2025-05-31 16:21:03 +02:00
// Copy example_prd.txt to NEW location
copyTemplateFile('example_prd.txt', path.join(targetDir, EXAMPLE_PRD_FILE));
2025-04-09 00:25:27 +02:00
// Initialize git repository if git is available
try {
if (!fs.existsSync(path.join(targetDir, '.git'))) {
log('info', 'Initializing git repository...');
execSync('git init', { stdio: 'ignore' });
log('success', 'Git repository initialized');
}
} catch (error) {
log('warn', 'Git not available, skipping repository initialization');
}
// Run npm install automatically
const npmInstallOptions = {
cwd: targetDir,
// Default to inherit for interactive CLI, change if silent
stdio: 'inherit'
};
if (isSilentMode()) {
// If silent (MCP mode), suppress npm install output
npmInstallOptions.stdio = 'ignore';
log('info', 'Running npm install silently...'); // Log our own message
} else {
// Interactive mode, show the boxen message
console.log(
boxen(chalk.cyan('Installing dependencies...'), {
padding: 0.5,
margin: 0.5,
borderStyle: 'round',
borderColor: 'blue'
})
);
}
2025-04-09 00:25:27 +02:00
// === Add Model Configuration Step ===
2025-05-31 16:21:03 +02:00
if (!isSilentMode() && !dryRun && !options?.yes) {
console.log(
boxen(chalk.cyan('Configuring AI Models...'), {
padding: 0.5,
margin: { top: 1, bottom: 0.5 },
borderStyle: 'round',
borderColor: 'blue'
})
);
log(
'info',
'Running interactive model setup. Please select your preferred AI models.'
);
try {
execSync('npx task-master models --setup', {
stdio: 'inherit',
cwd: targetDir
});
log('success', 'AI Models configured.');
} catch (error) {
log('error', 'Failed to configure AI models:', error.message);
log('warn', 'You may need to run "task-master models --setup" manually.');
}
} else if (isSilentMode() && !dryRun) {
log('info', 'Skipping interactive model setup in silent (MCP) mode.');
log(
'warn',
'Please configure AI models using "task-master models --set-..." or the "models" MCP tool.'
);
} else if (dryRun) {
log('info', 'DRY RUN: Skipping interactive model setup.');
2025-05-31 16:21:03 +02:00
} else if (options?.yes) {
log('info', 'Skipping interactive model setup due to --yes flag.');
log(
'info',
'Default AI models will be used. You can configure different models later using "task-master models --setup" or "task-master models --set-..." commands.'
2025-05-31 16:21:03 +02:00
);
2025-04-09 00:25:27 +02:00
}
// ====================================
2025-04-09 00:25:27 +02:00
// Display success message
if (!isSilentMode()) {
console.log(
boxen(
2025-05-31 16:21:03 +02:00
`${warmGradient.multiline(
figlet.textSync('Success!', { font: 'Standard' })
2025-05-31 16:21:03 +02:00
)}\n${chalk.green('Project initialized successfully!')}`,
{
padding: 1,
margin: 1,
borderStyle: 'double',
borderColor: 'green'
}
)
);
}
2025-04-09 00:25:27 +02:00
// Display next steps in a nice box
if (!isSilentMode()) {
console.log(
boxen(
2025-05-31 16:21:03 +02:00
`${chalk.cyan.bold('Things you should do next:')}\n\n${chalk.white('1. ')}${chalk.yellow(
'Configure AI models (if needed) and add API keys to `.env`'
)}\n${chalk.white(' ├─ ')}${chalk.dim('Models: Use `task-master models` commands')}\n${chalk.white(' └─ ')}${chalk.dim(
'Keys: Add provider API keys to .env (or inside the MCP config file i.e. .cursor/mcp.json)'
)}\n${chalk.white('2. ')}${chalk.yellow(
'Discuss your idea with AI and ask for a PRD using example_prd.txt, and save it to scripts/PRD.txt'
)}\n${chalk.white('3. ')}${chalk.yellow(
'Ask Cursor Agent (or run CLI) to parse your PRD and generate initial tasks:'
)}\n${chalk.white(' └─ ')}${chalk.dim('MCP Tool: ')}${chalk.cyan('parse_prd')}${chalk.dim(' | CLI: ')}${chalk.cyan('task-master parse-prd scripts/prd.txt')}\n${chalk.white('4. ')}${chalk.yellow(
'Ask Cursor to analyze the complexity of the tasks in your PRD using research'
)}\n${chalk.white(' └─ ')}${chalk.dim('MCP Tool: ')}${chalk.cyan('analyze_project_complexity')}${chalk.dim(' | CLI: ')}${chalk.cyan('task-master analyze-complexity')}\n${chalk.white('5. ')}${chalk.yellow(
'Ask Cursor to expand all of your tasks using the complexity analysis'
)}\n${chalk.white('6. ')}${chalk.yellow('Ask Cursor to begin working on the next task')}\n${chalk.white('7. ')}${chalk.yellow(
'Add new tasks anytime using the add-task command or MCP tool'
2025-05-31 16:21:03 +02:00
)}\n${chalk.white('8. ')}${chalk.yellow(
'Ask Cursor to set the status of one or many tasks/subtasks at a time. Use the task id from the task lists.'
)}\n${chalk.white('9. ')}${chalk.yellow(
2025-05-31 16:21:03 +02:00
'Ask Cursor to update all tasks from a specific task id based on new learnings or pivots in your project.'
)}\n${chalk.white('10. ')}${chalk.green.bold('Ship it!')}\n\n${chalk.dim(
2025-05-31 16:21:03 +02:00
'* Review the README.md file to learn how to use other commands via Cursor Agent.'
)}\n${chalk.dim(
'* Use the task-master command without arguments to see all available commands.'
)}`,
{
padding: 1,
margin: 1,
borderStyle: 'round',
borderColor: 'yellow',
title: 'Getting Started',
titleAlignment: 'center'
}
)
);
}
2025-03-04 13:55:17 -05:00
}
// Function to setup MCP configuration for Cursor integration
function setupMCPConfiguration(targetDir) {
2025-04-09 00:25:27 +02:00
const mcpDirPath = path.join(targetDir, '.cursor');
const mcpJsonPath = path.join(mcpDirPath, 'mcp.json');
log('info', 'Setting up MCP configuration for Cursor integration...');
// Create .cursor directory if it doesn't exist
ensureDirectoryExists(mcpDirPath);
// New MCP config to be added - references the installed package
const newMCPServer = {
'task-master-ai': {
command: 'npx',
args: ['-y', '--package=task-master-ai', 'task-master-ai'],
2025-04-09 00:25:27 +02:00
env: {
ANTHROPIC_API_KEY: 'ANTHROPIC_API_KEY_HERE',
PERPLEXITY_API_KEY: 'PERPLEXITY_API_KEY_HERE',
OPENAI_API_KEY: 'OPENAI_API_KEY_HERE',
GOOGLE_API_KEY: 'GOOGLE_API_KEY_HERE',
XAI_API_KEY: 'XAI_API_KEY_HERE',
OPENROUTER_API_KEY: 'OPENROUTER_API_KEY_HERE',
MISTRAL_API_KEY: 'MISTRAL_API_KEY_HERE',
AZURE_OPENAI_API_KEY: 'AZURE_OPENAI_API_KEY_HERE',
OLLAMA_API_KEY: 'OLLAMA_API_KEY_HERE'
2025-04-09 00:25:27 +02:00
}
}
};
// Check if mcp.json already existsimage.png
2025-04-09 00:25:27 +02:00
if (fs.existsSync(mcpJsonPath)) {
log(
'info',
'MCP configuration file already exists, checking for existing task-master-mcp...'
);
2025-04-09 00:25:27 +02:00
try {
// Read existing config
const mcpConfig = JSON.parse(fs.readFileSync(mcpJsonPath, 'utf8'));
// Initialize mcpServers if it doesn't exist
if (!mcpConfig.mcpServers) {
mcpConfig.mcpServers = {};
}
// Check if any existing server configuration already has task-master-mcp in its args
const hasMCPString = Object.values(mcpConfig.mcpServers).some(
(server) =>
server.args &&
server.args.some(
(arg) => typeof arg === 'string' && arg.includes('task-master-ai')
)
);
if (hasMCPString) {
log(
'info',
'Found existing task-master-ai MCP configuration in mcp.json, leaving untouched'
);
return; // Exit early, don't modify the existing configuration
}
2025-04-09 00:25:27 +02:00
// Add the task-master-ai server if it doesn't exist
if (!mcpConfig.mcpServers['task-master-ai']) {
mcpConfig.mcpServers['task-master-ai'] = newMCPServer['task-master-ai'];
log(
'info',
'Added task-master-ai server to existing MCP configuration'
);
} else {
log('info', 'task-master-ai server already configured in mcp.json');
}
// Write the updated configuration
fs.writeFileSync(mcpJsonPath, JSON.stringify(mcpConfig, null, 4));
log('success', 'Updated MCP configuration file');
} catch (error) {
log('error', `Failed to update MCP configuration: ${error.message}`);
// Create a backup before potentially modifying
const backupPath = `${mcpJsonPath}.backup-${Date.now()}`;
if (fs.existsSync(mcpJsonPath)) {
fs.copyFileSync(mcpJsonPath, backupPath);
log('info', `Created backup of existing mcp.json at ${backupPath}`);
}
// Create new configuration
const newMCPConfig = {
mcpServers: newMCPServer
};
fs.writeFileSync(mcpJsonPath, JSON.stringify(newMCPConfig, null, 4));
log(
'warn',
'Created new MCP configuration file (backup of original file was created if it existed)'
);
}
} else {
// If mcp.json doesn't exist, create it
const newMCPConfig = {
mcpServers: newMCPServer
};
fs.writeFileSync(mcpJsonPath, JSON.stringify(newMCPConfig, null, 4));
log('success', 'Created MCP configuration file for Cursor integration');
}
// Add note to console about MCP integration
log('info', 'MCP server will use the installed task-master-ai package');
}
// Ensure necessary functions are exported
export { initializeProject, log }; // Only export what's needed by commands.js