docs: document '.' as target for current worktree removal#20
Conversation
The path resolution already supports '.' to target the current worktree, but it was untested and undiscoverable. Add a test case and document it in the README so users know they can run `worktree-remove . --yes`.
Jercik
force-pushed
the
docs/dot-target-current-worktree
branch
from
a737752 to
de7b410
Compare
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| "devDependencies": { | ||
| "@total-typescript/ts-reset": "^0.6.1", | ||
| "@types/node": "^25.3.1", | ||
| "@types/node": "^25.3.3", |
There was a problem hiding this comment.
🟠 High: package.json updates @types/node and eslint-config-axkit, but pnpm-lock.yaml was not updated in this PR. This fails reproducibly with npx -y pnpm@10.30.3 install --frozen-lockfile (ERR_PNPM_OUTDATED_LOCKFILE, mismatched specifiers for both deps). I also checked .github/workflows/checks.yml and .github/workflows/release.yml, and both run pnpm install --frozen-lockfile, so CI/release installs will fail until the lockfile is regenerated and committed.
Jercik
left a comment
Jercik
left a comment
There was a problem hiding this comment.
Approach Review: The approach of adding a focused regression test for . resolution and documenting it is the right fix for the ‘works but undiscoverable’ problem. A potentially more discoverable alternative is to also add the worktree-remove . --yes example (or mention . as a supported target) in the CLI --help text, since that’s where users typically look first.
Approach review by Copilot (gpt-5.2)
| - branch name (for worktrees on a branch) | ||
| - worktree path (works for detached HEAD worktrees) | ||
| - directory name in the parent folder (useful when there's no branch) | ||
| - `.` (current directory — removes the worktree you are in) |
There was a problem hiding this comment.
Alternative approach: Consider also documenting . in the CLI --help output (e.g., add worktree-remove . --yes to the help examples / target description in src/cli.ts) to improve discoverability for users who never read the README.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a7377527db
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "@types/node": "^25.3.3", | ||
| "@vitest/coverage-v8": "^4.0.18", | ||
| "eslint": "^10.0.2", | ||
| "eslint-config-axkit": "^1.3.0", | ||
| "eslint-config-axkit": "^1.4.0", |
There was a problem hiding this comment.
These dependency specifier bumps are not accompanied by a pnpm-lock.yaml update, so CI will fail in this repo’s install step because the workflow enforces pnpm install --frozen-lockfile (.github/workflows/checks.yml:27). The lockfile importer still records @types/node as ^25.3.1 and eslint-config-axkit as ^1.3.0 (pnpm-lock.yaml:34,43), which no longer matches package.json, making the lockfile out of date for this commit.
Useful? React with 👍 / 👎.
| it("resolves current directory when input is '.'", () => { | ||
| const result = resolveWorktreeTarget({ | ||
| input: ".", | ||
| cwd: "/Users/acme/repo-feature/foo", |
There was a problem hiding this comment.
ℹ️ Info: Good test — it confirms that looksLikePathInput(".") returns true (line starts with "."), causing path.resolve(cwd, ".") to produce the cwd itself, which then matches the registered worktree.
Worth noting: this covers the case where cwd is the worktree root. If a user runs worktree-remove . from a subdirectory (e.g., repo-feature/foo/src), the resolved path wouldn't match the worktree root and would fall through to the candidates path — potentially treating the subdirectory as an orphaned directory. That's pre-existing behavior and outside this PR's scope, but could be worth a follow-up test or guard if it comes up.
| - branch name (for worktrees on a branch) | ||
| - worktree path (works for detached HEAD worktrees) | ||
| - directory name in the parent folder (useful when there's no branch) | ||
| - `.` (current directory — removes the worktree you are in) |
There was a problem hiding this comment.
ℹ️ Info: Nice addition. The parenthetical description is clear and consistent with the style of the other bullet points above.
| }); | ||
| }); | ||
|
|
||
| it("resolves current directory when input is '.'", () => { |
There was a problem hiding this comment.
ℹ️ Info: Good test coverage for the . input case. The test correctly verifies that "." resolves via path.resolve(cwd, ".") to the current directory, matches the registered worktree at that path, and returns isPathInput: true (since looksLikePathInput() returns true for inputs starting with .). The test data is well-structured with a distinct cwd that differs from mainPath, ensuring the resolution is actually using the cwd rather than defaulting.
|
🎉 This PR is included in version 1.4.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
1 participant
Summary
.input resolving to the current worktree inresolve-worktree-target.test.ts.as a supported target format in the README (Manual Mode section and Examples)The path resolution already supports
.to remove the current worktree (worktree-remove . --yes), but it was untested and undiscoverable.Test plan
pnpm testpasses (54 tests, including the new one)