feat: add changelog highlights to auto-update notifications#1286
feat: add changelog highlights to auto-update notifications#1286Crunchyman-ralph merged 6 commits intonextfrom
Conversation
🦋 Changeset detectedLatest commit: 3fd5312 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
WalkthroughAdds parsing and display of versioned CHANGELOG "Minor Changes" highlights to the CLI auto-update flow: UpdateInfo now may include Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant User
participant CLI as "CLI Command"
participant AutoUpdate as "apps/cli/src/utils/auto-update.ts"
participant CDN as "unpkg CDN"
User->>CLI: run command
CLI->>AutoUpdate: checkForUpdate(currentVersion)
AutoUpdate->>AutoUpdate: determine latestVersion, needsUpdate
alt update available
AutoUpdate->>CDN: GET /.../CHANGELOG.md@latestVersion
CDN-->>AutoUpdate: CHANGELOG.md (or error)
AutoUpdate->>AutoUpdate: parseChangelogHighlights(changelog, version)
AutoUpdate-->>CLI: UpdateInfo{currentVersion, latestVersion, highlights?}
CLI->>AutoUpdate: displayUpgradeNotification(curr, latest, highlights)
AutoUpdate-->>User: print update notice + optional "What's New" list
else up-to-date
AutoUpdate-->>CLI: UpdateInfo(needsUpdate=false)
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro 📒 Files selected for processing (1)
🧰 Additional context used📓 Path-based instructions (1)package.json📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)
Files:
🧠 Learnings (1)📚 Learning: 2025-09-26T19:10:32.906ZApplied to files:
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (16)
.changeset/auto-update-changelog-highlights.md(1 hunks).taskmaster/config.json(1 hunks).taskmaster/docs/autonomous-tdd-git-workflow.md(1 hunks).taskmaster/docs/tdd-workflow-phase-0-spike.md(1 hunks).taskmaster/docs/tdd-workflow-phase-1-core-rails.md(1 hunks).taskmaster/docs/tdd-workflow-phase-2-pr-resumability.md(1 hunks).taskmaster/docs/tdd-workflow-phase-3-extensibility-guardrails.md(1 hunks).taskmaster/reports/task-complexity-report_autonomous-tdd-git-workflow.json(1 hunks).taskmaster/reports/task-complexity-report_tdd-workflow-phase-0.json(1 hunks).taskmaster/state.json(1 hunks)apps/cli/src/utils/auto-update.ts(5 hunks)docs/contributor-docs/worktree-setup.md(1 hunks)scripts/create-worktree.sh(1 hunks)scripts/list-worktrees.sh(1 hunks)scripts/modules/commands.js(1 hunks)tests/unit/commands.test.js(1 hunks)
🧰 Additional context used
📓 Path-based instructions (20)
.taskmaster/config.json
📄 CodeRabbit inference engine (.cursor/rules/dev_workflow.mdc)
.taskmaster/config.json: Store Taskmaster configuration settings (AI model selections, parameters, logging level, default subtasks/priority, project name, etc.) in the.taskmaster/config.jsonfile located in the project root directory. Do not configure non-API key settings via environment variables.
Do not manually edit.taskmaster/config.jsonunless you are certain of the changes; use thetask-master modelscommand ormodelsMCP tool for configuration.
.taskmaster/config.json: Do not manually edit the .taskmaster/config.json file. Use the included commands either in the MCP or CLI format as needed. Always prioritize MCP tools when available and use the CLI as a fallback.
All other Taskmaster settings (model choice, max tokens, temperature, log level, custom endpoints) are managed in .taskmaster/config.json via the task-master models command or models MCP tool.
Do not manually edit the .taskmaster/config.json file; always use the provided CLI or MCP tools for configuration changes.
Files:
.taskmaster/config.json
scripts/modules/commands.js
📄 CodeRabbit inference engine (.cursor/rules/ai_services.mdc)
scripts/modules/commands.js: Centralize all LLM calls throughgenerateTextServiceorgenerateObjectService.
Do not import or call anything from the oldai-services.js,ai-client-factory.js, orai-client-utils.jsfiles.
Do not fetch AI-specific parameters (model ID, max tokens, temp) usingconfig-manager.jsgetters for the AI call. Pass theroleinstead.
Do not implement fallback or retry logic outsideai-services-unified.js.
Do not handle API key resolution outside the service layer (it usesutils.jsinternally).
Determine the appropriaterole(main,research,fallback) in your core logic and pass it to the service.
Pass thesessionobject (received in thecontextparameter, especially from direct function wrappers) to the service call when in MCP context.
UsegenerateTextServiceand implement robust manual JSON parsing (with Zod validation after parsing) when structured output is needed, asgenerateObjectServicehas shown unreliability with some providers/schemas.
Be aware of potential reliability issues withgenerateObjectServiceacross different providers and complex schemas. PrefergenerateTextService+ manual parsing as a more robust alternative for structured data needs.
scripts/modules/commands.js: All new user-facing commands should be added to 'scripts/modules/commands.js'.
Use consistent patterns for option naming and help text in CLI commands.
Follow the Commander.js model for subcommand structure in CLI commands.
When using callbacks (like in Commander.js commands), define them separately to allow testing the callback logic independently.
Add help text to the command definition and update 'dev_workflow.mdc' with command reference when adding a new feature.
Follow the established pattern in 'commands.js' for CLI command implementation, using Commander.js for argument parsing, including comprehensive help text and examples, and supporting tagged task context awareness.
Provide clear error messages for common failu...
Files:
scripts/modules/commands.js
scripts/modules/*.js
📄 CodeRabbit inference engine (.cursor/rules/architecture.mdc)
Each module in scripts/modules/ should be focused on a single responsibility, following the modular architecture (e.g., commands.js for CLI command handling, task-manager.js for task data and core logic, dependency-manager.js for dependency management, ui.js for CLI output formatting, ai-services-unified.js for AI service integration, config-manager.js for configuration management, utils.js for utility functions).
scripts/modules/*.js: Export all core functions, helper functions, and utility methods needed by your new function or command from their respective modules. Explicitly review the module's export block to ensure every required dependency is included.
Pass all required parameters to functions you call within your implementation and verify that direct function parameters match their core function counterparts.
Use consistent file naming conventions: 'task_${id.toString().padStart(3, '0')}.txt', use path.join for composing file paths, and use appropriate file extensions (.txt for tasks, .json for data).
Use structured error objects with code and message properties, include clear error messages, and handle both function-specific and file system errors.
Import all silent mode utilities together from 'scripts/modules/utils.js' and always use isSilentMode() to check global silent mode status. Wrap core function calls within direct functions using enableSilentMode() and disableSilentMode() in a try/finally block if the core function might produce console output.
Core functions should check outputFormat === 'text' before displaying UI elements and use internal logging that respects silent mode.
Design functions to accept dependencies as parameters (dependency injection) and avoid hard-coded dependencies that are difficult to mock.
Keep pure logic separate from I/O operations or UI rendering to allow testing the logic without mocking complex dependencies.
When implementing core logic for new features, do so in 'scripts/modules/' before CLI or MCP interfaces, and d...
Files:
scripts/modules/commands.js
scripts/modules/**
📄 CodeRabbit inference engine (.cursor/rules/dev_workflow.mdc)
When using the MCP server, restart it if core logic in
scripts/modulesor MCP tool/direct function definitions change.
Files:
scripts/modules/commands.js
scripts/modules/*
📄 CodeRabbit inference engine (.cursor/rules/tags.mdc)
scripts/modules/*: Every command that reads or writes tasks.json must be tag-aware
All command files must import getCurrentTag from utils.js
Every CLI command that operates on tasks must include the --tag CLI option
All commands must resolve the tag using the pattern: options.tag || getCurrentTag(projectRoot) || 'master'
All commands must find projectRoot with error handling before proceeding
All commands must pass { projectRoot, tag } as context to core functions
MCP direct functions must accept and use a context object containing projectRoot and tag, and pass them to core functions
Do not hard-code tag resolution (e.g., const tag = options.tag || 'master';); always use getCurrentTag
Do not omit the --tag CLI option in commands that operate on tasks
Do not omit the context parameter when calling core functions from commands
Do not call readJSON or writeJSON without passing projectRoot and tag
Files:
scripts/modules/commands.js
**/*.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
**/*.js: Declare and initialize global variables at the top of modules to avoid hoisting issues.
Use proper function declarations to avoid hoisting issues and initialize variables before they are referenced.
Do not reference variables before their declaration in module scope.
Use dynamic imports (import()) to avoid initialization order issues in modules.
Files:
scripts/modules/commands.jstests/unit/commands.test.js
tests/{unit,integration,e2e,fixtures}/**/*.js
📄 CodeRabbit inference engine (.cursor/rules/architecture.mdc)
Test files must be organized as follows: unit tests in tests/unit/, integration tests in tests/integration/, end-to-end tests in tests/e2e/, and test fixtures in tests/fixtures/.
Files:
tests/unit/commands.test.js
tests/unit/*.js
📄 CodeRabbit inference engine (.cursor/rules/architecture.mdc)
Each module should have a corresponding unit test file in tests/unit/ that reflects the module structure (one test file per module).
Files:
tests/unit/commands.test.js
**/*.{test,spec}.{js,ts,jsx,tsx}
📄 CodeRabbit inference engine (.cursor/rules/git_workflow.mdc)
**/*.{test,spec}.{js,ts,jsx,tsx}: Create a test file and ensure all tests pass when all subtasks are complete; commit tests if added or modified
When all subtasks are complete, run final testing using the appropriate test runner (e.g., npm test, jest, or manual testing)
Files:
tests/unit/commands.test.js
**/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
**/*.test.js: Never use asynchronous operations in tests. Make all mocks return synchronous values when possible.
Always mock tests properly based on the way the tested functions are defined and used.
Follow the test file organization: mocks must be set up before importing modules under test, and spies on mocked modules should be set up after imports.
Use fixtures from tests/fixtures/ for consistent sample data across tests.
Always declare mocks before importing the modules being tested in Jest test files.
Use jest.spyOn() after imports to create spies on mock functions and reference these spies in test assertions.
When testing functions with callbacks, get the callback from your mock's call arguments, execute it directly with test inputs, and verify the results.
For ES modules, use jest.mock() before static imports and jest.unstable_mockModule() before dynamic imports to mock dependencies.
Reset mock functions (mockFn.mockReset()) before dynamic imports if they might have been called previously.
When verifying console assertions, assert against the actual arguments passed (single formatted string), not multiple arguments.
Use mock-fs to mock file system operations in tests, and restore the file system after each test.
Mock API calls (e.g., Anthropic/Claude) by mocking the entire module and providing predictable responses.
Set mock environment variables in test setup and restore them after each test.
Maintain test fixtures separate from test logic.
Follow the mock-first-then-import pattern for all Jest mocks.
Do not define mock variables before jest.mock() calls (they won't be accessible due to hoisting).
Use test-specific file paths (e.g., 'test-tasks.json') for all file operations in tests.
Mock readJSON and writeJSON to avoid real file system interactions in tests.
Verify file operations use the correct paths in expect statements.
Use different file paths for each test to avoid test interdependence.
Verify modifications on the in-memory task objects passed to w...
Files:
tests/unit/commands.test.js
tests/unit/**/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
tests/unit/**/*.test.js: Unit tests must be located in tests/unit/, test individual functions and utilities in isolation, mock all external dependencies, and keep tests small, focused, and fast.
Do not include actual command execution in unit tests.
Files:
tests/unit/commands.test.js
tests/{unit,integration,e2e}/**/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
tests/{unit,integration,e2e}/**/*.test.js: When testing CLI commands built with Commander.js, test the command action handlers directly rather than trying to mock the entire Commander.js chain.
When mocking the Commander.js chain, mock ALL chainable methods (option, argument, action, on, etc.) and return this (or the mock object) from all chainable method mocks.
Explicitly handle all options, including defaults and shorthand flags (e.g., -p for --prompt), and include null/undefined checks in test implementations for parameters that might be optional.
Do not try to use the real action implementation without proper mocking, and do not mock Commander partially—either mock it completely or test the action directly.
Mock the action handlers for CLI commands and verify they're called with correct arguments.
Use sample task fixtures for consistent test data, mock file system operations, and test both success and error paths for task operations.
Mock console output and verify correct formatting in UI function tests. Use flexible assertions like toContain() or toMatch() for formatted output.
Mock chalk functions to return the input text to make testing easier while still verifying correct function calls.
Files:
tests/unit/commands.test.js
**/*.{test,spec}.*
📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)
Test files should follow naming conventions: .test., .spec., or _test. depending on the language
Files:
tests/unit/commands.test.js
tests/{unit,integration,e2e}/**
📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)
Organize test directories by test type (unit, integration, e2e) and mirror source structure where possible
Files:
tests/unit/commands.test.js
**/*.{test,spec}.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.{test,spec}.{js,jsx,ts,tsx}: NEVER use async/await in test functions unless testing actual asynchronous operations
Use synchronous top-level imports in tests; avoid dynamic await import()
Keep test bodies synchronous whenever possible
Files:
tests/unit/commands.test.js
.taskmaster/state.json
📄 CodeRabbit inference engine (.cursor/rules/dev_workflow.mdc)
Track Taskmaster's current tag context and migration status in
.taskmaster/state.json, which is automatically created and managed by the system.
Files:
.taskmaster/state.json
docs/**/*
📄 CodeRabbit inference engine (.cursor/rules/new_features.mdc)
Add feature documentation to '/docs' folder, include tagged system usage examples, update command reference documentation, and provide migration notes if relevant.
Files:
docs/contributor-docs/worktree-setup.md
.changeset/*.md
📄 CodeRabbit inference engine (.cursor/rules/changeset.mdc)
.changeset/*.md: When runningnpm run changesetornpx changeset add, provide a concise summary of the changes for theCHANGELOG.mdin imperative mood, typically a single line, and not a detailed Git commit message.
The changeset summary should be user-facing, describing what changed in the released version that is relevant to users or consumers of the package.
Do not use your detailed Git commit message body as the changeset summary.
Files:
.changeset/auto-update-changelog-highlights.md
.changeset/*
📄 CodeRabbit inference engine (.cursor/rules/new_features.mdc)
Create appropriate changesets for new features, use semantic versioning, include tagged system information in release notes, and document breaking changes if any.
Files:
.changeset/auto-update-changelog-highlights.md
.changeset/**/*.md
📄 CodeRabbit inference engine (CLAUDE.md)
Changeset entries should be user-facing, describing the end-user impact rather than code specifics
Files:
.changeset/auto-update-changelog-highlights.md
🧠 Learnings (14)
📚 Learning: 2025-07-31T22:08:16.039Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/taskmaster.mdc:0-0
Timestamp: 2025-07-31T22:08:16.039Z
Learning: Applies to .taskmaster/config.json : All other Taskmaster settings (model choice, max tokens, temperature, log level, custom endpoints) are managed in .taskmaster/config.json via the task-master models command or models MCP tool.
Applied to files:
.taskmaster/config.json
📚 Learning: 2025-07-18T17:08:48.695Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-18T17:08:48.695Z
Learning: Applies to scripts/modules/commands.js : Implement version checking to notify users of available updates, use non-blocking version checks, and display update notifications after command completion.
Applied to files:
scripts/modules/commands.js
📚 Learning: 2025-07-31T22:07:49.716Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-31T22:07:49.716Z
Learning: Applies to scripts/modules/commands.js : Implement semantic version comparison and display attractive update notifications using boxen.
Applied to files:
scripts/modules/commands.jsapps/cli/src/utils/auto-update.ts
📚 Learning: 2025-07-31T22:07:49.716Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-31T22:07:49.716Z
Learning: Applies to scripts/modules/commands.js : Integrate version checking in the CLI run function, starting the update check in the background and displaying notifications after command execution.
Applied to files:
scripts/modules/commands.js
📚 Learning: 2025-07-31T22:08:16.039Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/taskmaster.mdc:0-0
Timestamp: 2025-07-31T22:08:16.039Z
Learning: Applies to {.taskmaster/tasks/tasks.json,.taskmaster/reports/task-complexity-report.json,.taskmaster/docs/research/**} : Do not manually edit generated files such as .taskmaster/tasks/tasks.json, .taskmaster/reports/task-complexity-report.json, or files in .taskmaster/docs/research/. Always use Taskmaster commands to modify these files.
Applied to files:
.taskmaster/reports/task-complexity-report_tdd-workflow-phase-0.json
📚 Learning: 2025-09-24T15:12:12.658Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: assets/.windsurfrules:0-0
Timestamp: 2025-09-24T15:12:12.658Z
Learning: Use task-master complexity-report to view formatted complexity insights and recommendations
Applied to files:
.taskmaster/reports/task-complexity-report_tdd-workflow-phase-0.json.taskmaster/reports/task-complexity-report_autonomous-tdd-git-workflow.json
📚 Learning: 2025-09-24T15:12:12.658Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: assets/.windsurfrules:0-0
Timestamp: 2025-09-24T15:12:12.658Z
Learning: Analyze task complexity with task-master analyze-complexity --research and use results to plan breakdown
Applied to files:
.taskmaster/reports/task-complexity-report_tdd-workflow-phase-0.json
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Use AI to generate detailed subtasks within the current tag context, considering complexity analysis for subtask counts and ensuring proper IDs for newly created subtasks.
Applied to files:
.taskmaster/reports/task-complexity-report_tdd-workflow-phase-0.json
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to tests/{unit,integration,e2e}/**/*.test.js : Mock console output and verify correct formatting in UI function tests. Use flexible assertions like toContain() or toMatch() for formatted output.
Applied to files:
tests/unit/commands.test.js
📚 Learning: 2025-07-18T17:10:53.657Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/glossary.mdc:0-0
Timestamp: 2025-07-18T17:10:53.657Z
Learning: Describes the high-level architecture of the Task Master CLI application, including the new tagged task lists system (architecture.mdc).
Applied to files:
.taskmaster/docs/autonomous-tdd-git-workflow.md
📚 Learning: 2025-07-18T17:10:53.657Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/glossary.mdc:0-0
Timestamp: 2025-07-18T17:10:53.657Z
Learning: Guidelines for integrating new features into the Task Master CLI with tagged system considerations (new_features.mdc).
Applied to files:
.taskmaster/docs/autonomous-tdd-git-workflow.md
📚 Learning: 2025-07-18T17:10:53.657Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/glossary.mdc:0-0
Timestamp: 2025-07-18T17:10:53.657Z
Learning: Guide for using Task Master to manage task-driven development workflows with tagged task lists support (dev_workflow.mdc).
Applied to files:
.taskmaster/docs/autonomous-tdd-git-workflow.md
📚 Learning: 2025-07-18T17:10:53.657Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/glossary.mdc:0-0
Timestamp: 2025-07-18T17:10:53.657Z
Learning: Guidelines for implementing and maintaining tests for Task Master CLI (tests.mdc).
Applied to files:
.taskmaster/docs/autonomous-tdd-git-workflow.md
📚 Learning: 2025-07-18T17:10:12.881Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/dev_workflow.mdc:0-0
Timestamp: 2025-07-18T17:10:12.881Z
Learning: Applies to .taskmaster/state.json : Track Taskmaster's current tag context and migration status in `.taskmaster/state.json`, which is automatically created and managed by the system.
Applied to files:
.taskmaster/state.json
🧬 Code graph analysis (1)
tests/unit/commands.test.js (2)
apps/cli/src/utils/auto-update.ts (1)
displayUpgradeNotification(243-268)apps/cli/src/index.ts (1)
displayUpgradeNotification(30-30)
🪛 ast-grep (0.39.6)
apps/cli/src/utils/auto-update.ts
[warning] 120-120: Regular expression constructed from variable input detected. This can lead to Regular Expression Denial of Service (ReDoS) attacks if the variable contains malicious patterns. Use libraries like 'recheck' to validate regex safety or use static patterns.
Context: new RegExp(## ${version.replace(/\./g, '\\.')}\\s*\\n, 'i')
Note: [CWE-1333] Inefficient Regular Expression Complexity [REFERENCES]
- https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS
- https://cwe.mitre.org/data/definitions/1333.html
(regexp-from-variable)
🪛 markdownlint-cli2 (0.18.1)
.taskmaster/docs/autonomous-tdd-git-workflow.md
1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
297-297: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
339-339: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
339-339: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
428-428: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
429-429: Strong style
Expected: asterisk; Actual: underscore
(MD050, strong-style)
429-429: Strong style
Expected: asterisk; Actual: underscore
(MD050, strong-style)
435-435: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
435-435: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
505-505: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
513-513: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
519-519: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
525-525: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
550-550: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
852-852: Inconsistent indentation for list items at the same level
Expected: 0; Actual: 1
(MD005, list-indent)
852-852: Unordered list indentation
Expected: 0; Actual: 1
(MD007, ul-indent)
docs/contributor-docs/worktree-setup.md
45-45: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
52-52: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
77-77: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
119-119: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
215-215: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
221-221: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
230-230: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
238-238: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
246-246: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
257-257: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
265-265: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
273-273: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
291-291: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
301-301: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
314-314: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
361-361: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
369-369: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
382-382: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
.changeset/auto-update-changelog-highlights.md
5-5: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
7-7: Files should end with a single newline character
(MD047, single-trailing-newline)
.taskmaster/docs/tdd-workflow-phase-3-extensibility-guardrails.md
3-3: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
6-6: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
18-18: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
55-55: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
82-82: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
109-109: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
140-140: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
172-172: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
182-182: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
199-199: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
199-199: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
220-220: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
273-273: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
281-281: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
306-306: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
328-328: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
346-346: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
382-382: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
405-405: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
432-432: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
476-476: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
484-484: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
492-492: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
498-498: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
506-506: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
511-511: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
514-514: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
527-527: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
.taskmaster/docs/tdd-workflow-phase-0-spike.md
3-3: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
6-6: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
14-14: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
20-20: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
26-26: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
38-38: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
91-91: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
97-97: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
104-104: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
110-110: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
115-115: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
118-118: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
🔇 Additional comments (8)
.taskmaster/config.json (1)
4-7: Confirm provider/model compatibility.Switching the main provider to
"claude-code"with"modelId": "sonnet"might break Taskmaster if that provider key or model identifier isn’t recognized. Please verify the CLI/agent actually accepts this tuple before merging. Based on learnings.apps/cli/src/utils/auto-update.ts (4)
11-16: LGTM! Backwards-compatible interface extension.The optional
highlightsfield is properly typed and maintains backwards compatibility with existing code.
63-110: LGTM! Robust error handling with graceful degradation.The function properly handles:
- HTTP errors (non-200 status codes)
- Network failures (request errors)
- Timeouts (3-second limit)
- Parsing errors
All error cases gracefully return an empty array, ensuring the auto-update flow continues uninterrupted even if highlights are unavailable.
187-216: LGTM! Clean integration of highlight fetching.The modifications properly:
- Only fetch highlights when an update is actually needed (performance optimization)
- Handle the async nature of
fetchChangelogHighlights- Maintain backwards compatibility by including highlights conditionally
- Preserve existing error handling for the main update check
243-268: LGTM! User-friendly presentation of highlights.The notification logic cleanly handles both cases:
- When highlights are available: displays a "What's New:" section with bullet points
- When highlights are unavailable: shows a generic update message
The backwards-compatible signature (optional parameter) ensures existing callers continue to work.
scripts/modules/commands.js (1)
5112-5116: LGTM! Proper integration with updated notification function.The code correctly passes
updateInfo.highlightstodisplayUpgradeNotification, completing the integration of the new highlights feature. The undefined case is properly handled by the notification function.tests/unit/commands.test.js (2)
306-322: LGTM! Comprehensive test coverage for highlights display.The test properly verifies:
- The "What's New:" section is rendered
- Version information is displayed
- All provided highlights are included in the output
The use of realistic sample highlights makes the test more meaningful.
Based on learnings
324-331: LGTM! Proper test coverage for the fallback scenario.The test correctly verifies that when highlights are unavailable (empty array):
- The "What's New:" section is not displayed
- The default update message is shown instead
This ensures graceful degradation when highlights cannot be fetched.
Based on learnings
Display "What's New" section in auto-update notifications showing all Minor Changes from CHANGELOG. Fetches changelog from unpkg.com CDN with graceful fallback. - Add fetchChangelogHighlights() to fetch CHANGELOG.md from CDN - Add parseChangelogHighlights() to extract Minor Changes - Update displayUpgradeNotification() to show highlights - Include highlights in UpdateInfo interface - Add comprehensive unit tests 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Crunchyman-ralph
force-pushed
the
ralph/feat/auto.update.changelog
branch
from
fa3a087 to
0ebcf7f
Compare
Add semver validation before constructing regex to prevent potential ReDoS attacks. While the version parameter comes from a trusted source (npm registry), this provides defense-in-depth security. - Add semver pattern validation in parseChangelogHighlights() - Export function for testing with @internal annotation - Add comprehensive tests for valid/invalid version formats - Test includes malicious input patterns 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (1)
apps/cli/src/utils/auto-update.ts (1)
121-121: Address ReDoS risk with version validation.The dynamic regex construction at line 121 poses a potential ReDoS risk, as flagged by static analysis and a previous review. While the version comes from npm (trusted source), adding validation provides defense-in-depth.
Consider adding version validation before regex construction:
function parseChangelogHighlights( changelog: string, version: string ): string[] { try { + // Validate version format (basic semver pattern) + if (!/^\d+\.\d+\.\d+(-[a-zA-Z0-9.-]+)?$/.test(version)) { + return []; + } + // Find the version section const versionRegex = new RegExp(`## ${version.replace(/\./g, '\\.')}\\s*\\n`, 'i');As per past review comments
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (4)
.changeset/auto-update-changelog-highlights.md(1 hunks)apps/cli/src/utils/auto-update.ts(5 hunks)scripts/modules/commands.js(1 hunks)tests/unit/commands.test.js(1 hunks)
🧰 Additional context used
📓 Path-based instructions (17)
scripts/modules/commands.js
📄 CodeRabbit inference engine (.cursor/rules/ai_services.mdc)
scripts/modules/commands.js: Centralize all LLM calls throughgenerateTextServiceorgenerateObjectService.
Do not import or call anything from the oldai-services.js,ai-client-factory.js, orai-client-utils.jsfiles.
Do not fetch AI-specific parameters (model ID, max tokens, temp) usingconfig-manager.jsgetters for the AI call. Pass theroleinstead.
Do not implement fallback or retry logic outsideai-services-unified.js.
Do not handle API key resolution outside the service layer (it usesutils.jsinternally).
Determine the appropriaterole(main,research,fallback) in your core logic and pass it to the service.
Pass thesessionobject (received in thecontextparameter, especially from direct function wrappers) to the service call when in MCP context.
UsegenerateTextServiceand implement robust manual JSON parsing (with Zod validation after parsing) when structured output is needed, asgenerateObjectServicehas shown unreliability with some providers/schemas.
Be aware of potential reliability issues withgenerateObjectServiceacross different providers and complex schemas. PrefergenerateTextService+ manual parsing as a more robust alternative for structured data needs.
scripts/modules/commands.js: All new user-facing commands should be added to 'scripts/modules/commands.js'.
Use consistent patterns for option naming and help text in CLI commands.
Follow the Commander.js model for subcommand structure in CLI commands.
When using callbacks (like in Commander.js commands), define them separately to allow testing the callback logic independently.
Add help text to the command definition and update 'dev_workflow.mdc' with command reference when adding a new feature.
Follow the established pattern in 'commands.js' for CLI command implementation, using Commander.js for argument parsing, including comprehensive help text and examples, and supporting tagged task context awareness.
Provide clear error messages for common failu...
Files:
scripts/modules/commands.js
scripts/modules/*.js
📄 CodeRabbit inference engine (.cursor/rules/architecture.mdc)
Each module in scripts/modules/ should be focused on a single responsibility, following the modular architecture (e.g., commands.js for CLI command handling, task-manager.js for task data and core logic, dependency-manager.js for dependency management, ui.js for CLI output formatting, ai-services-unified.js for AI service integration, config-manager.js for configuration management, utils.js for utility functions).
scripts/modules/*.js: Export all core functions, helper functions, and utility methods needed by your new function or command from their respective modules. Explicitly review the module's export block to ensure every required dependency is included.
Pass all required parameters to functions you call within your implementation and verify that direct function parameters match their core function counterparts.
Use consistent file naming conventions: 'task_${id.toString().padStart(3, '0')}.txt', use path.join for composing file paths, and use appropriate file extensions (.txt for tasks, .json for data).
Use structured error objects with code and message properties, include clear error messages, and handle both function-specific and file system errors.
Import all silent mode utilities together from 'scripts/modules/utils.js' and always use isSilentMode() to check global silent mode status. Wrap core function calls within direct functions using enableSilentMode() and disableSilentMode() in a try/finally block if the core function might produce console output.
Core functions should check outputFormat === 'text' before displaying UI elements and use internal logging that respects silent mode.
Design functions to accept dependencies as parameters (dependency injection) and avoid hard-coded dependencies that are difficult to mock.
Keep pure logic separate from I/O operations or UI rendering to allow testing the logic without mocking complex dependencies.
When implementing core logic for new features, do so in 'scripts/modules/' before CLI or MCP interfaces, and d...
Files:
scripts/modules/commands.js
scripts/modules/**
📄 CodeRabbit inference engine (.cursor/rules/dev_workflow.mdc)
When using the MCP server, restart it if core logic in
scripts/modulesor MCP tool/direct function definitions change.
Files:
scripts/modules/commands.js
scripts/modules/*
📄 CodeRabbit inference engine (.cursor/rules/tags.mdc)
scripts/modules/*: Every command that reads or writes tasks.json must be tag-aware
All command files must import getCurrentTag from utils.js
Every CLI command that operates on tasks must include the --tag CLI option
All commands must resolve the tag using the pattern: options.tag || getCurrentTag(projectRoot) || 'master'
All commands must find projectRoot with error handling before proceeding
All commands must pass { projectRoot, tag } as context to core functions
MCP direct functions must accept and use a context object containing projectRoot and tag, and pass them to core functions
Do not hard-code tag resolution (e.g., const tag = options.tag || 'master';); always use getCurrentTag
Do not omit the --tag CLI option in commands that operate on tasks
Do not omit the context parameter when calling core functions from commands
Do not call readJSON or writeJSON without passing projectRoot and tag
Files:
scripts/modules/commands.js
**/*.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
**/*.js: Declare and initialize global variables at the top of modules to avoid hoisting issues.
Use proper function declarations to avoid hoisting issues and initialize variables before they are referenced.
Do not reference variables before their declaration in module scope.
Use dynamic imports (import()) to avoid initialization order issues in modules.
Files:
scripts/modules/commands.jstests/unit/commands.test.js
tests/{unit,integration,e2e,fixtures}/**/*.js
📄 CodeRabbit inference engine (.cursor/rules/architecture.mdc)
Test files must be organized as follows: unit tests in tests/unit/, integration tests in tests/integration/, end-to-end tests in tests/e2e/, and test fixtures in tests/fixtures/.
Files:
tests/unit/commands.test.js
tests/unit/*.js
📄 CodeRabbit inference engine (.cursor/rules/architecture.mdc)
Each module should have a corresponding unit test file in tests/unit/ that reflects the module structure (one test file per module).
Files:
tests/unit/commands.test.js
**/*.{test,spec}.{js,ts,jsx,tsx}
📄 CodeRabbit inference engine (.cursor/rules/git_workflow.mdc)
**/*.{test,spec}.{js,ts,jsx,tsx}: Create a test file and ensure all tests pass when all subtasks are complete; commit tests if added or modified
When all subtasks are complete, run final testing using the appropriate test runner (e.g., npm test, jest, or manual testing)
Files:
tests/unit/commands.test.js
**/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
**/*.test.js: Never use asynchronous operations in tests. Make all mocks return synchronous values when possible.
Always mock tests properly based on the way the tested functions are defined and used.
Follow the test file organization: mocks must be set up before importing modules under test, and spies on mocked modules should be set up after imports.
Use fixtures from tests/fixtures/ for consistent sample data across tests.
Always declare mocks before importing the modules being tested in Jest test files.
Use jest.spyOn() after imports to create spies on mock functions and reference these spies in test assertions.
When testing functions with callbacks, get the callback from your mock's call arguments, execute it directly with test inputs, and verify the results.
For ES modules, use jest.mock() before static imports and jest.unstable_mockModule() before dynamic imports to mock dependencies.
Reset mock functions (mockFn.mockReset()) before dynamic imports if they might have been called previously.
When verifying console assertions, assert against the actual arguments passed (single formatted string), not multiple arguments.
Use mock-fs to mock file system operations in tests, and restore the file system after each test.
Mock API calls (e.g., Anthropic/Claude) by mocking the entire module and providing predictable responses.
Set mock environment variables in test setup and restore them after each test.
Maintain test fixtures separate from test logic.
Follow the mock-first-then-import pattern for all Jest mocks.
Do not define mock variables before jest.mock() calls (they won't be accessible due to hoisting).
Use test-specific file paths (e.g., 'test-tasks.json') for all file operations in tests.
Mock readJSON and writeJSON to avoid real file system interactions in tests.
Verify file operations use the correct paths in expect statements.
Use different file paths for each test to avoid test interdependence.
Verify modifications on the in-memory task objects passed to w...
Files:
tests/unit/commands.test.js
tests/unit/**/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
tests/unit/**/*.test.js: Unit tests must be located in tests/unit/, test individual functions and utilities in isolation, mock all external dependencies, and keep tests small, focused, and fast.
Do not include actual command execution in unit tests.
Files:
tests/unit/commands.test.js
tests/{unit,integration,e2e}/**/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
tests/{unit,integration,e2e}/**/*.test.js: When testing CLI commands built with Commander.js, test the command action handlers directly rather than trying to mock the entire Commander.js chain.
When mocking the Commander.js chain, mock ALL chainable methods (option, argument, action, on, etc.) and return this (or the mock object) from all chainable method mocks.
Explicitly handle all options, including defaults and shorthand flags (e.g., -p for --prompt), and include null/undefined checks in test implementations for parameters that might be optional.
Do not try to use the real action implementation without proper mocking, and do not mock Commander partially—either mock it completely or test the action directly.
Mock the action handlers for CLI commands and verify they're called with correct arguments.
Use sample task fixtures for consistent test data, mock file system operations, and test both success and error paths for task operations.
Mock console output and verify correct formatting in UI function tests. Use flexible assertions like toContain() or toMatch() for formatted output.
Mock chalk functions to return the input text to make testing easier while still verifying correct function calls.
Files:
tests/unit/commands.test.js
**/*.{test,spec}.*
📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)
Test files should follow naming conventions: .test., .spec., or _test. depending on the language
Files:
tests/unit/commands.test.js
tests/{unit,integration,e2e}/**
📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)
Organize test directories by test type (unit, integration, e2e) and mirror source structure where possible
Files:
tests/unit/commands.test.js
**/*.{test,spec}.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.{test,spec}.{js,jsx,ts,tsx}: NEVER use async/await in test functions unless testing actual asynchronous operations
Use synchronous top-level imports in tests; avoid dynamic await import()
Keep test bodies synchronous whenever possible
Files:
tests/unit/commands.test.js
.changeset/*.md
📄 CodeRabbit inference engine (.cursor/rules/changeset.mdc)
.changeset/*.md: When runningnpm run changesetornpx changeset add, provide a concise summary of the changes for theCHANGELOG.mdin imperative mood, typically a single line, and not a detailed Git commit message.
The changeset summary should be user-facing, describing what changed in the released version that is relevant to users or consumers of the package.
Do not use your detailed Git commit message body as the changeset summary.
Files:
.changeset/auto-update-changelog-highlights.md
.changeset/*
📄 CodeRabbit inference engine (.cursor/rules/new_features.mdc)
Create appropriate changesets for new features, use semantic versioning, include tagged system information in release notes, and document breaking changes if any.
Files:
.changeset/auto-update-changelog-highlights.md
.changeset/**/*.md
📄 CodeRabbit inference engine (CLAUDE.md)
Changeset entries should be user-facing, describing the end-user impact rather than code specifics
Files:
.changeset/auto-update-changelog-highlights.md
🧠 Learnings (5)
📚 Learning: 2025-07-31T22:07:49.716Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-31T22:07:49.716Z
Learning: Applies to scripts/modules/commands.js : Implement semantic version comparison and display attractive update notifications using boxen.
Applied to files:
apps/cli/src/utils/auto-update.tsscripts/modules/commands.js
📚 Learning: 2025-07-18T17:08:48.695Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-18T17:08:48.695Z
Learning: Applies to scripts/modules/commands.js : Implement version checking to notify users of available updates, use non-blocking version checks, and display update notifications after command completion.
Applied to files:
scripts/modules/commands.js
📚 Learning: 2025-07-31T22:07:49.716Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-31T22:07:49.716Z
Learning: Applies to scripts/modules/commands.js : Integrate version checking in the CLI run function, starting the update check in the background and displaying notifications after command execution.
Applied to files:
scripts/modules/commands.js
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to tests/{unit,integration,e2e}/**/*.test.js : Mock console output and verify correct formatting in UI function tests. Use flexible assertions like toContain() or toMatch() for formatted output.
Applied to files:
tests/unit/commands.test.js
📚 Learning: 2025-07-18T17:07:53.100Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/changeset.mdc:0-0
Timestamp: 2025-07-18T17:07:53.100Z
Learning: Applies to .changeset/*.md : When running `npm run changeset` or `npx changeset add`, provide a concise summary of the changes for the `CHANGELOG.md` in imperative mood, typically a single line, and not a detailed Git commit message.
Applied to files:
.changeset/auto-update-changelog-highlights.md
🧬 Code graph analysis (2)
apps/cli/src/utils/auto-update.ts (1)
test-version-check-full.js (1)
needsUpdate(27-28)
tests/unit/commands.test.js (1)
apps/cli/src/utils/auto-update.ts (1)
displayUpgradeNotification(243-268)
🪛 ast-grep (0.39.6)
apps/cli/src/utils/auto-update.ts
[warning] 120-120: Regular expression constructed from variable input detected. This can lead to Regular Expression Denial of Service (ReDoS) attacks if the variable contains malicious patterns. Use libraries like 'recheck' to validate regex safety or use static patterns.
Context: new RegExp(## ${version.replace(/\./g, '\\.')}\\s*\\n, 'i')
Note: [CWE-1333] Inefficient Regular Expression Complexity [REFERENCES]
- https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS
- https://cwe.mitre.org/data/definitions/1333.html
(regexp-from-variable)
🪛 GitHub Actions: CI
apps/cli/src/utils/auto-update.ts
[error] 119-134: Formatter would have reformatted the file. Code changes suggested by biome format. Run 'biome format .' to apply fixes.
tests/unit/commands.test.js
[error] 317-334: Formatter would have reformatted the file. Run 'biome format .' to apply fixes.
🪛 markdownlint-cli2 (0.18.1)
.changeset/auto-update-changelog-highlights.md
5-5: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
7-7: Files should end with a single newline character
(MD047, single-trailing-newline)
🔇 Additional comments (6)
scripts/modules/commands.js (1)
5114-5115: LGTM! Correctly passes highlights to notification.The addition of
updateInfo.highlightsas a third parameter todisplayUpgradeNotificationcorrectly integrates the new changelog highlights feature. The optional nature of highlights ensures backward compatibility.tests/unit/commands.test.js (1)
306-322: LGTM! Comprehensive test for highlights display.The test correctly verifies that when highlights are provided, the notification includes a "What's New:" section with all the changelog highlights. The assertions properly check for the presence of all key elements.
apps/cli/src/utils/auto-update.ts (4)
15-15: LGTM! Clean interface extension.The addition of the optional
highlightsfield to theUpdateInfointerface maintains backward compatibility and is properly typed.
63-110: LGTM! Well-designed fetch function with graceful fallback.The implementation correctly:
- Sets a reasonable 3-second timeout to avoid blocking
- Gracefully handles errors by returning an empty array
- Uses unpkg.com CDN for changelog retrieval
- Handles all error paths consistently
The non-blocking timeout and graceful degradation align with the PR objectives.
187-208: LGTM! Efficient and graceful highlights integration.The changes correctly:
- Make the callback async to support awaiting
fetchChangelogHighlights- Only fetch highlights when an update is needed (efficient)
- Include highlights in the returned
UpdateInfoobject- Maintain backward compatibility with graceful fallback
The conditional fetching optimizes performance by avoiding unnecessary network requests.
243-268: LGTM! Well-structured notification display with highlights.The updated function correctly:
- Accepts an optional
highlightsparameter (backward compatible)- Conditionally renders a "What's New:" section when highlights are available
- Falls back to a default message when highlights are absent or empty
- Maintains consistent formatting with boxen
The implementation provides a user-friendly display while gracefully handling the absence of highlights.
Crunchyman-ralph
force-pushed
the
ralph/feat/auto.update.changelog
branch
from
13b5acb to
80ed1c7
Compare
Fetch CHANGELOG.md from GitHub main branch instead of unpkg CDN. - Change hostname from unpkg.com to raw.githubusercontent.com - Use main branch path: /eyaltoledano/claude-task-master/main/CHANGELOG.md - More reliable as GitHub is always available - Always gets the latest CHANGELOG from main branch 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Crunchyman-ralph
force-pushed
the
ralph/feat/auto.update.changelog
branch
from
80ed1c7 to
4199fe7
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
apps/cli/src/utils/auto-update.ts(5 hunks)package.json(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
package.json
📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)
Add and update test scripts in package.json to include test, test:watch, test:coverage, test:unit, test:integration, test:e2e, and test:ci
Files:
package.json
🧠 Learnings (3)
📓 Common learnings
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-18T17:08:48.695Z
Learning: Applies to scripts/modules/commands.js : Implement version checking to notify users of available updates, use non-blocking version checks, and display update notifications after command completion.
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-31T22:07:49.716Z
Learning: Applies to scripts/modules/commands.js : Implement version checking to notify users of available updates, use non-blocking version checks, and display update notifications after command completion.
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-31T22:07:49.716Z
Learning: Applies to scripts/modules/commands.js : Implement semantic version comparison and display attractive update notifications using boxen.
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-18T17:08:48.695Z
Learning: Applies to scripts/modules/commands.js : Implement semantic version comparison and display attractive update notifications using boxen.
📚 Learning: 2025-09-26T19:10:32.906Z
Learnt from: Crunchyman-ralph
PR: eyaltoledano/claude-task-master#1252
File: tsconfig.json:22-28
Timestamp: 2025-09-26T19:10:32.906Z
Learning: In the eyaltoledano/claude-task-master repository, all internal tm/ package path mappings in tsconfig.json consistently point to TypeScript source files (e.g., "./packages/*/src/index.ts") rather than built JavaScript. This is intentional architecture because tsdown bundles internal packages directly from source during build time, eliminating the need for separate compilation of internal packages.
Applied to files:
package.json
📚 Learning: 2025-07-31T22:07:49.716Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-31T22:07:49.716Z
Learning: Applies to scripts/modules/commands.js : Implement semantic version comparison and display attractive update notifications using boxen.
Applied to files:
apps/cli/src/utils/auto-update.ts
🧬 Code graph analysis (1)
apps/cli/src/utils/auto-update.ts (3)
tests/unit/commands.test.js (1)
parseChangelogHighlights(282-282)test-version-check-full.js (1)
needsUpdate(27-28)scripts/modules/commands.js (1)
currentVersion(5099-5099)
🪛 ast-grep (0.39.6)
apps/cli/src/utils/auto-update.ts
[warning] 126-129: Regular expression constructed from variable input detected. This can lead to Regular Expression Denial of Service (ReDoS) attacks if the variable contains malicious patterns. Use libraries like 'recheck' to validate regex safety or use static patterns.
Context: new RegExp(
## ${version.replace(/\./g, '\\.')}\\s*\\n,
'i'
)
Note: [CWE-1333] Inefficient Regular Expression Complexity [REFERENCES]
- https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS
- https://cwe.mitre.org/data/definitions/1333.html
(regexp-from-variable)
🪛 GitHub Actions: CI
package.json
[error] 119-127: Biome format check failed. The formatter would modify the following content in package.json. Run 'npm run format-check' (or 'biome format .') to apply fixes.
🔇 Additional comments (4)
apps/cli/src/utils/auto-update.ts (4)
11-16: LGTM!The addition of the optional
highlightsproperty to theUpdateInfointerface is well-designed and maintains backward compatibility.
116-171: LGTM with note on ReDoS mitigation.The parsing logic correctly extracts "Minor Changes" from the changelog. The version validation at lines 121-124 effectively mitigates the ReDoS risk flagged by static analysis at lines 126-129. The regex construction is safe because the version string is validated against a strict semver pattern before being used in the RegExp constructor.
Note: The static analysis warning is a false positive given the upfront validation.
199-220: LGTM!The modification to conditionally fetch highlights only when an update is needed is efficient and correct. The async/await handling is proper, and the optional nature of highlights ensures backward compatibility.
Note: This depends on the
fetchChangelogHighlightsfunction being corrected to fetch from the version-specific source.
255-282: LGTM!The updated notification display logic is well-implemented:
- Backward compatible with the optional
highlightsparameter- Clear conditional rendering based on highlights availability
- Professional formatting with proper use of chalk and boxen
- Graceful fallback to a generic message when highlights are unavailable
Based on learnings
…dano#1286) Co-authored-by: Claude <noreply@anthropic.com>
1 participant
Summary
Adds a "What's New" section to auto-update notifications that displays all Minor Changes from the CHANGELOG. When users auto-update to a new version, they now see the key features and improvements immediately without having to manually check the changelog.
Changes
fetchChangelogHighlights(): Fetches CHANGELOG.md from unpkg.com CDN for the new versionparseChangelogHighlights(): Extracts all Minor Changes from the changelog using regex parsingdisplayUpgradeNotification(): Shows "What's New" section with bullet points when highlights are availableUpdateInfointerface: Added optionalhighlightsfieldImplementation Details
unpkg.com/task-master-ai@{version}/CHANGELOG.md/^-\s+\[#\d+\][^\n]*?!\s+-\s+(.+?)$/gmExample Output
Test Plan
displayUpgradeNotification()with/without highlightsBenefits
✅ Non-blocking - 3-second timeout won't slow down updates
✅ Graceful degradation - Falls back to generic message on error
✅ Zero maintenance - Works with existing changeset workflow
✅ User-friendly - Shows all important changes in clean format
✅ CDN-based - Reliable unpkg.com source
🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Documentation
Tests
Chores