ros/claude-task-master
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
615633196c9947bd7bd545634afd2c3099f9aa87
claude-task-master/.changeset
History
Eyal Toledano e607c5481c feat(paths): Implement robust project root detection and path utilities 
Overhauls the project root detection system with a hierarchical precedence mechanism that intelligently locates tasks.json and identifies project roots. This improves user experience by reducing the need for explicit path parameters and enhances cross-platform compatibility.

Key Improvements:
- Implement hierarchical precedence for project root detection:
  * Environment variable override (TASK_MASTER_PROJECT_ROOT)
  * Explicitly provided --project-root parameter
  * Cached project root from previous successful operations
  * Current directory with project markers
  * Parent directory traversal to find tasks.json
  * Package directory as fallback

- Create comprehensive PROJECT_MARKERS detection system with 20+ common indicators:
  * Task Master specific files (tasks.json, tasks/tasks.json)
  * Version control directories (.git, .svn)
  * Package manifests (package.json, pyproject.toml, Gemfile, go.mod, Cargo.toml)
  * IDE/editor configurations (.cursor, .vscode, .idea)
  * Dependency directories (node_modules, venv, .venv)
  * Configuration files (.env, tsconfig.json, webpack.config.js)
  * CI/CD files (.github/workflows, .gitlab-ci.yml, .circleci/config.yml)

- DRY refactoring of path utilities:
  * Centralize path-related functions in core/utils/path-utils.js
  * Export PROJECT_MARKERS as a single source of truth
  * Add caching via lastFoundProjectRoot for performance optimization

- Enhanced user experience:
  * Improve error messages with specific troubleshooting guidance
  * Add detailed logging to indicate project root detection source
  * Update tool parameter descriptions for better clarity
  * Add recursive parent directory searching for tasks.json

Testing:
- Verified in local dev environment
- Added unit tests for the progress bar visualization
- Updated "automatically detected" description in MCP tools

This commit addresses Task #38: Implement robust project root handling for file paths.
2025-04-08 15:53:47 -04:00
..
config.json
chore: fix ci p1
2025-03-29 09:29:50 +01:00
fifty-squids-wear.md
CHORE: Add CI for making sure PRs don't break things (#89)
2025-04-03 16:01:58 +02:00
README.md
feat: Implement MCP (#20)
2025-03-28 20:38:53 +01:00
red-lights-mix.md
fix: github actions (#82)
2025-04-02 01:53:29 +02:00
two-bats-smoke.md
feat(paths): Implement robust project root detection and path utilities
2025-04-08 15:53:47 -04:00

README.md

Changesets

This folder has been automatically generated by @changesets/cli, a build tool that works with multi-package repos or single-package repos to help version and publish code. Full documentation is available in the Changesets repository.

What are Changesets?

Changesets are a way to track changes to packages in your repository. Each changeset:

  • Describes the changes you've made
  • Specifies the type of version bump needed (patch, minor, or major)
  • Connects these changes with release notes
  • Automates the versioning and publishing process

How to Use Changesets in Task Master

2. Making Changes

  1. Create a new branch for your changes
  2. Make your code changes
  3. Write tests and ensure all tests pass

3. Creating a Changeset

After making changes, create a changeset by running:

npx changeset

This will:

  • Walk you through a CLI to describe your changes
  • Ask you to select impact level (patch, minor, major)
  • Create a markdown file in the .changeset directory

4. Impact Level Guidelines

When choosing the impact level for your changes:

  • Patch: Bug fixes and minor changes that don't affect how users interact with the system
    • Example: Fixing a typo in output text, optimizing code without changing behavior
  • Minor: New features or enhancements that don't break existing functionality
    • Example: Adding a new flag to an existing command, adding new task metadata fields
  • Major: Breaking changes that require users to update their usage
    • Example: Renaming a command, changing the format of the tasks.json file

5. Writing Good Changeset Descriptions

Your changeset description should:

  • Be written for end-users, not developers
  • Clearly explain what changed and why
  • Include any migration steps or backward compatibility notes
  • Reference related issues or pull requests with #issue-number

Examples:

# Good

Added new `--research` flag to the `expand` command that uses Perplexity AI
to provide research-backed task expansions. Requires PERPLEXITY_API_KEY
environment variable.

# Not Good

Fixed stuff and added new flag

6. Committing Your Changes

Commit both your code changes and the generated changeset file:

git add .
git commit -m "Add feature X with changeset"
git push

7. Pull Request Process

  1. Open a pull request
  2. Ensure CI passes
  3. Await code review
  4. Once approved and merged, your changeset will be used during the next release

Release Process (for Maintainers)

When it's time to make a release:

  1. Ensure all desired changesets are merged
  2. Run npx changeset version to update package versions and changelog
  3. Review and commit the changes
  4. Run npm publish to publish to npm

This can be automated through Github Actions

Common Issues and Solutions

  • Merge Conflicts in Changeset Files: Resolve just like any other merge conflict
  • Multiple Changes in One PR: Create multiple changesets if changes affect different areas
  • Accidentally Committed Without Changeset: Create the changeset after the fact and commit it separately

Additional Resources