-
Notifications
You must be signed in to change notification settings - Fork 0
Promote Release: v1.0.0-beta.1 → main #6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Add: Test suits files for all managers
Release v1.0.0-beta.1
…tya13/plain-git into release/v1.0.0-beta.1
fix: auto remote + upstream for push action
Merge the latest remoteManager
WalkthroughThe changes add comprehensive unit test coverage using Vitest for all Manager classes, introduce test infrastructure (helpers and mocks), migrate from Jest to Vitest, add module path aliases via jsconfig.json and tsconfig.json, bump version to 1.0.0-beta.1, update package metadata, refactor RemoteManager push logic to handle zero-remotes scenarios, and improve string type handling in MergeManager. Changes
Sequence DiagramsequenceDiagram
actor User
participant RemoteManager
participant GitExecutor
participant git as git CLI
User->>RemoteManager: pushChanges()
alt No remotes exist
RemoteManager->>User: Prompt for remote URL
User-->>RemoteManager: Provide URL
RemoteManager->>GitExecutor: git remote add origin <url>
GitExecutor->>git: add origin
end
RemoteManager->>GitExecutor: git rev-parse --abbrev-ref HEAD
GitExecutor->>git: Get current branch
git-->>GitExecutor: branch name
RemoteManager->>GitExecutor: git rev-parse --abbrev-ref <branch>@{upstream}
GitExecutor->>git: Check upstream
alt No upstream configured
GitExecutor-->>RemoteManager: Error/empty
RemoteManager->>GitExecutor: git push -u origin <branch>
GitExecutor->>git: push with upstream
else Upstream exists
GitExecutor-->>RemoteManager: Upstream found
RemoteManager->>GitExecutor: git push
GitExecutor->>git: standard push
end
git-->>GitExecutor: Success
GitExecutor-->>RemoteManager: Complete
RemoteManager-->>User: Push completed
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Areas requiring extra attention:
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 5
🧹 Nitpick comments (6)
.gitignore (1)
6-7: Consider removing redundant ignore path.The
tests/sandbox/repo/entry is redundant sincetests/sandbox/already covers all subdirectories recursively.Apply this diff to simplify:
coverage tests/sandbox/ -tests/sandbox/repo/package.json (1)
45-56: Remove unused Jest dependencies after Vitest migration.The test script now uses Vitest (line 12), but Jest-related packages remain in devDependencies. These should be removed to keep the dependency tree clean.
Apply this diff to remove unused dependencies:
"devDependencies": { - "@types/jest": "^30.0.0", "@types/node": "^24.10.1", "eslint": "^9.39.1", "execa": "^9.6.0", "husky": "^9.1.7", - "jest": "^30.2.0", "lint-staged": "^16.2.6", "nodemon": "^3.1.10", "prettier": "^3.6.2", "rimraf": "^6.1.0", "strip-ansi": "^7.1.2", - "ts-jest": "^29.4.5", "ts-node": "^10.9.2",tests/unit/RepositoryManager.test.ts (1)
22-22: Consider removing redundant dynamic imports.The test file statically imports
RepositoryManagerat Line 3, but then dynamically re-imports it at Lines 22, 37, 57, and throughout the file. Since the tests mockGitExecutor.runrather than the manager itself, the dynamic imports appear unnecessary and add complexity.If the dynamic imports serve a specific purpose (e.g., ensuring mocks are applied), add a comment explaining why. Otherwise, use the static import from Line 3:
- const {RepositoryManager} = await import("@/managers") - await RepositoryManager.initRepo(); + await RepositoryManager.initRepo();Also applies to: 37-37
src/managers/RemoteManager.ts (2)
134-135: Remove unused array mutation.Line 134 pushes
'origin'to theremotesarray after adding the remote, but this array is not used anywhere afterward in the function. The subsequent logic (Lines 138-160) doesn't reference theremotesvariable.Remove the unused line:
Logger.info(`🔗 Adding remote origin → ${url}`); await GitExecutor.run(`git remote add origin ${url}`); - remotes.push('origin'); }
122-161: Consider extracting upstream detection into a helper function.The
pushChangesmethod now handles multiple responsibilities: detecting remotes, adding remotes if needed, checking upstream tracking, and performing the push. This increases complexity and makes the method harder to test and maintain.Consider extracting the upstream detection logic (Lines 141-146) into a helper function:
function hasUpstream(): boolean { try { execSync('git rev-parse --abbrev-ref --symbolic-full-name @{u}'); return true; } catch { return false; } }Similarly, extract the current branch detection into
getCurrentBranch()helper. This would improve readability and allow unit testing these components independently.tests/unit/MergeManager.test.ts (1)
196-217: Consider refactoring to avoidvi.resetModules()pattern.The use of
vi.resetModules()followed by re-importing modules suggests potential module-level state issues. This pattern makes tests more complex and harder to maintain.Consider whether the manager modules have shared state that persists between tests. If so, refactoring to reduce or eliminate module-level state would improve testability.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (22)
.gitignore(1 hunks)README.md(1 hunks)jsconfig.json(1 hunks)package.json(2 hunks)src/cli/index.ts(0 hunks)src/managers/MergeManager.ts(2 hunks)src/managers/RemoteManager.ts(2 hunks)tests/helpers/testRepo.ts(1 hunks)tests/mocks/inquirerMock.ts(1 hunks)tests/unit/BranchManager.test.ts(1 hunks)tests/unit/CommitManager.test.ts(1 hunks)tests/unit/ConflictManager.test.ts(1 hunks)tests/unit/HistoryManager.test.ts(1 hunks)tests/unit/MergeManager.test.ts(1 hunks)tests/unit/RebaseManager.test.ts(1 hunks)tests/unit/RemoteManager.test.ts(1 hunks)tests/unit/RepositoryManager.test.ts(1 hunks)tests/unit/ResetManager.test.ts(1 hunks)tests/unit/StashManager.test.ts(1 hunks)tests/unit/TagManager.test.ts(1 hunks)tsconfig.json(1 hunks)vitest.config.ts(1 hunks)
💤 Files with no reviewable changes (1)
- src/cli/index.ts
🧰 Additional context used
🧬 Code graph analysis (12)
tests/unit/RebaseManager.test.ts (2)
src/core/GitExecutor.ts (1)
GitExecutor(8-67)tests/mocks/inquirerMock.ts (1)
mockInquirer(41-51)
tests/unit/CommitManager.test.ts (2)
src/core/GitExecutor.ts (1)
GitExecutor(8-67)tests/mocks/inquirerMock.ts (1)
mockInquirer(41-51)
tests/unit/RepositoryManager.test.ts (3)
tests/helpers/testRepo.ts (1)
createTestRepo(5-16)tests/mocks/inquirerMock.ts (1)
mockInquirer(41-51)src/core/GitExecutor.ts (1)
GitExecutor(8-67)
src/managers/RemoteManager.ts (2)
src/utils/Logger.ts (1)
Logger(3-23)src/core/GitExecutor.ts (1)
GitExecutor(8-67)
tests/unit/ConflictManager.test.ts (2)
src/core/GitExecutor.ts (1)
GitExecutor(8-67)tests/mocks/inquirerMock.ts (1)
mockInquirer(41-51)
tests/unit/TagManager.test.ts (2)
src/core/GitExecutor.ts (1)
GitExecutor(8-67)tests/mocks/inquirerMock.ts (1)
mockInquirer(41-51)
tests/unit/MergeManager.test.ts (3)
src/core/GitExecutor.ts (1)
GitExecutor(8-67)src/managers/MergeManager.ts (1)
MergeManager(39-152)tests/mocks/inquirerMock.ts (1)
mockInquirer(41-51)
tests/unit/ResetManager.test.ts (2)
src/core/GitExecutor.ts (1)
GitExecutor(8-67)tests/mocks/inquirerMock.ts (1)
mockInquirer(41-51)
tests/unit/RemoteManager.test.ts (2)
tests/mocks/inquirerMock.ts (2)
clearInquirerQueue(53-55)mockInquirer(41-51)src/core/GitExecutor.ts (1)
GitExecutor(8-67)
tests/unit/HistoryManager.test.ts (2)
tests/mocks/inquirerMock.ts (1)
mockInquirer(41-51)src/core/GitExecutor.ts (1)
GitExecutor(8-67)
tests/unit/StashManager.test.ts (2)
tests/mocks/inquirerMock.ts (1)
mockInquirer(41-51)src/core/GitExecutor.ts (1)
GitExecutor(8-67)
tests/unit/BranchManager.test.ts (2)
tests/mocks/inquirerMock.ts (1)
mockInquirer(41-51)src/core/GitExecutor.ts (1)
GitExecutor(8-67)
🪛 markdownlint-cli2 (0.18.1)
README.md
2-2: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3
(MD001, heading-increment)
🔇 Additional comments (17)
jsconfig.json (1)
1-8: LGTM! Path alias configuration is correct.The jsconfig.json properly configures module path aliases for JavaScript/IDE tooling, aligning with the TypeScript and Vitest configurations introduced in this PR.
tsconfig.json (1)
1-23: LGTM! TypeScript configuration updates are well-aligned.The path aliases, allowJs, and simplified include directive properly support the new test infrastructure and module resolution strategy.
vitest.config.ts (1)
1-20: LGTM! Vitest configuration is well-structured.The configuration properly enables global test APIs, sets up Node environment, configures coverage reporting, and establishes path aliases that align with the project's TypeScript and JavaScript configurations.
tests/unit/BranchManager.test.ts (1)
1-190: LGTM! Comprehensive test suite with proper mocking strategy.The test suite demonstrates excellent coverage of BranchManager functionality:
- Correct mock setup before module imports (lines 9-17)
- Dynamic imports ensure mock isolation
- All nine core operations tested with appropriate assertions
- Consistent use of mockInquirer for prompt simulation
The approach of mocking
child_processbefore imports and using dynamic imports in each test ensures test isolation and prevents mock pollution between test cases.tests/unit/TagManager.test.ts (1)
1-175: Well-structured test suite with comprehensive coverage.The test suite covers all major TagManager operations including edge cases (no tags, cancellation flows). The use of mocked
execSyncto simulate tag lists and the dynamic import pattern ensures proper test isolation.src/managers/MergeManager.ts (1)
53-58: Good addition: filtering HEAD references from branch list.Line 58 adds a filter to exclude lines containing 'HEAD' from the branch list, preventing detached HEAD states and HEAD references from appearing in the merge target selection. This improves the user experience.
tests/unit/RebaseManager.test.ts (1)
1-275: Comprehensive test coverage with proper mock isolation.The test suite demonstrates thorough coverage of RebaseManager functionality, including:
- Blocking operations when rebase is in progress
- Handling empty branch lists
- Conflict detection and reporting
- Interactive rebase flows
The use of
vi.resetModules()in Lines 147, 182, and 230 ensures proper mock propagation for state-dependent tests. This is a solid testing pattern.tests/unit/RemoteManager.test.ts (1)
132-226: Excellent test coverage for the refactored pushChanges flow.The test suite thoroughly validates the new multi-step push logic:
- Lines 132-156: Handles zero remotes by prompting for URL and performing first push
- Lines 158-180: Sets upstream when missing
- Lines 182-202: Performs normal push when upstream exists
- Lines 205-226: Validates the complete flow
The mock sequencing with
mockReturnValueOncecorrectly simulates the multipleexecSynccalls in the implementation.tests/mocks/inquirerMock.ts (1)
1-55: Well-designed mock utility for inquirer prompts.The queue-based approach effectively handles both single prompts and arrays of prompts. The persistent mock pattern (Lines 8-39) ensures the mock survives across multiple test calls, which is essential for the dynamic import pattern used throughout the test suite.
The defensive try-catch at Lines 45-50 prevents setup failures while allowing test execution to proceed.
tests/unit/CommitManager.test.ts (1)
1-227: Comprehensive test suite with excellent edge case coverage.The test suite validates all CommitManager operations including:
- Stage operations (all files, selective, unstage)
- Commit flows (normal, amend, undo)
- Display operations (log, diff, last commit)
- Edge cases: empty messages (Lines 98-108), no files (Lines 38-48), user selecting none (Lines 50-62)
The test structure is clear and maintainable.
tests/unit/StashManager.test.ts (1)
1-195: LGTM! Comprehensive test coverage for StashManager.The test suite is well-structured with excellent coverage of all StashManager methods across multiple scenarios:
- Proper mock setup with
child_processmocked before module import- Dynamic imports ensure clean test isolation
- Good coverage of edge cases (empty stashes, user cancellations, etc.)
- Clear test descriptions and expectations
tests/unit/HistoryManager.test.ts (1)
1-227: LGTM! Excellent test coverage for HistoryManager.This test suite demonstrates thorough coverage of all HistoryManager methods with well-designed test cases:
- Proper mock setup with
child_processandspawnmocked- Tests cover both empty states and populated states
- Edge cases handled (no commits, no files, insufficient data)
- Command validation via GitExecutor.run spy is precise
tests/unit/MergeManager.test.ts (1)
1-256: Comprehensive test coverage for MergeManager.The test suite provides excellent coverage of MergeManager functionality:
- Sophisticated fs.existsSync mocking to simulate merge states
- Tests cover merge blocking, conflicts, abort scenarios
- Good validation of GitExecutor.run invocations
- Edge cases handled (no branches, no merge active, cancellations)
tests/unit/ConflictManager.test.ts (2)
79-103: Excellent conflict marker detection testing.The test effectively simulates conflict markers in file content and validates the inspection logic. The multi-line string with HEAD, branch markers, and separator is a realistic test case.
1-189: Comprehensive ConflictManager test suite.The test suite provides thorough coverage:
- Well-designed fs mocking for existsSync and readFileSync
- Tests cover listing, inspecting, editing, and diffing conflicts
- Good edge case handling (no conflicts, no markers)
- Validation of editor integration (VSCode command)
tests/unit/ResetManager.test.ts (2)
173-243: Excellent routing logic validation.The interactiveReset tests effectively validate the routing logic by spying on internal methods. This approach tests the orchestration without re-testing the underlying implementations, which is a good testing practice.
1-244: Comprehensive ResetManager test suite.The test suite provides thorough coverage across all reset operations:
- All reset modes tested (soft, mixed, hard)
- Good confirmation flow testing (cancel vs confirm)
- Excellent coverage of edge cases (no commits, no files)
- Smart use of spies to validate routing in interactiveReset
- Better type casting pattern with
as unknown as vi.Mock
| @@ -1,13 +1,78 @@ | |||
| # 🧰 plain-git | |||
| # 🚀 plain-git | |||
| ### _Operate Git in plain English — a fully interactive, human-friendly Git CLI_ | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix heading level increment.
The heading level jumps from h1 to h3, skipping h2. Markdown best practices require incrementing heading levels by one at a time.
Apply this diff:
-### _Operate Git in plain English — a fully interactive, human-friendly Git CLI_
+## _Operate Git in plain English — a fully interactive, human-friendly Git CLI_📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ### _Operate Git in plain English — a fully interactive, human-friendly Git CLI_ | |
| ## _Operate Git in plain English — a fully interactive, human-friendly Git CLI_ |
🧰 Tools
🪛 markdownlint-cli2 (0.18.1)
2-2: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3
(MD001, heading-increment)
🤖 Prompt for AI Agents
In README.md around lines 2 to 2, the heading currently uses an h3 ("###
_Operate Git in plain English — a fully interactive, human-friendly Git CLI_")
immediately after the h1, skipping h2; change the heading level from h3 to h2
(replace "###" with "##") so heading levels progress incrementally and conform
to Markdown best practices.
| const output = (execSync('git diff --name-only --diff-filter=U', { | ||
| encoding: 'utf-8', | ||
| }); | ||
| return output.split('\n').filter(Boolean); | ||
| }) as unknown as string) ?? ''; | ||
| return String(output).split('\n').filter(Boolean); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
Unusual type casting pattern—verify TypeScript configuration.
Lines 30 and 53 use (execSync(...) as unknown as string) to cast the result. Since execSync with encoding: 'utf-8' should already return string according to Node.js types, the double cast through unknown suggests a potential TypeScript configuration issue or type mismatch.
Please verify:
- Is there a specific reason for the double cast?
- Check if the TypeScript version or
@types/nodeversion might be causing type inference issues.
Also applies to: 53-54
🏁 Script executed:
#!/bin/bash
# Check if there are other locations where execSync is used without this casting pattern
rg -A2 -B2 "execSync\(" --type=ts -g '!*.test.ts' | head -50Length of output: 2743
I need to investigate further why only MergeManager.ts uses this double casting pattern while other files don't.
---
🏁 Script executed:
```shell
#!/bin/bash
# Check the full context of MergeManager.ts around the casting locations
cat src/managers/MergeManager.ts | head -60
Length of output: 1813
🏁 Script executed:
#!/bin/bash
# Check tsconfig.json and package.json for TypeScript and @types/node versions
cat tsconfig.jsonLength of output: 498
🏁 Script executed:
#!/bin/bash
# Check package.json for dependency versions
cat package.json | grep -A5 -B5 '"@types/node"'Length of output: 297
🏁 Script executed:
#!/bin/bash
# Compare RemoteManager.ts (which doesn't use double cast) to see if there's a structural difference
cat src/managers/RemoteManager.ts | head -60Length of output: 1599
---
🏁 Script executed:
```shell
#!/bin/bash
# Check if removing the cast would be problematic by looking at what operations follow
cat src/managers/MergeManager.ts | grep -A10 "getConflictedFiles"
Length of output: 936
🏁 Script executed:
#!/bin/bash
# Verify the actual usage of output variable to see if the multiple casts are necessary
cat src/managers/MergeManager.ts | sed -n '25,40p'Length of output: 355
Remove unnecessary double type casting in MergeManager.ts (lines 30-33 and 53-54).
The double cast (execSync(...) as unknown as string) is unnecessary. Since execSync with encoding: 'utf-8' returns string according to Node.js type definitions, and all other files in the codebase (RemoteManager, TagManager, ResetManager, BranchDetector) use the same pattern without casting, this can be simplified to match the codebase convention:
const output = execSync('git diff --name-only --diff-filter=U', {
encoding: 'utf-8',
}) ?? '';The subsequent String(output) wrapper also becomes unnecessary once the cast is removed.
🤖 Prompt for AI Agents
In src/managers/MergeManager.ts around lines 30-33 and 53-54, remove the
unnecessary double cast and String() wrapper: replace "(execSync(...) as unknown
as string)" and "String(output)" with a single call to execSync(..., { encoding:
'utf-8' }) which already returns a string, fall back to '' with ?? if needed,
and then directly call .split('\n').filter(Boolean) on that result; apply the
same simplification at the second occurrence.
| } | ||
|
|
||
| // Step 2 — Detect current branch | ||
| const currentBranch = execSync('git rev-parse --abbrev-ref HEAD', { encoding: 'utf-8' }).trim(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add error handling for execSync to prevent crashes.
Line 138 calls execSync to detect the current branch without error handling. If this command fails (e.g., not in a Git repository, detached HEAD state), it will throw an uncaught exception and crash the process.
Apply this diff to add error handling:
- const currentBranch = execSync('git rev-parse --abbrev-ref HEAD', { encoding: 'utf-8' }).trim();
+ let currentBranch: string;
+ try {
+ currentBranch = execSync('git rev-parse --abbrev-ref HEAD', { encoding: 'utf-8' }).trim();
+ } catch (error) {
+ Logger.error('❌ Failed to detect current branch.');
+ return;
+ }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const currentBranch = execSync('git rev-parse --abbrev-ref HEAD', { encoding: 'utf-8' }).trim(); | |
| let currentBranch: string; | |
| try { | |
| currentBranch = execSync('git rev-parse --abbrev-ref HEAD', { encoding: 'utf-8' }).trim(); | |
| } catch (error) { | |
| Logger.error('❌ Failed to detect current branch.'); | |
| return; | |
| } |
🤖 Prompt for AI Agents
In src/managers/RemoteManager.ts around line 138, the call to execSync('git
rev-parse --abbrev-ref HEAD') is unprotected and will throw if Git is
unavailable or in a detached HEAD; wrap this call in a try/catch, log the caught
error (using the module's logger or console) and set a safe fallback value for
currentBranch (e.g., 'unknown' or an empty string) so the process does not
crash, and ensure subsequent code handles the fallback branch value.
| execSync('git init', { cwd: repoPath }); | ||
| return repoPath; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Configure git user identity to prevent test failures.
The test repository initialization doesn't set user.name and user.email, which are required for git commit operations. Tests that create commits will fail with git errors.
Apply this diff to add git configuration:
execSync('git init', { cwd: repoPath });
+execSync('git config user.name "Test User"', { cwd: repoPath });
+execSync('git config user.email "test@example.com"', { cwd: repoPath });
return repoPath;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| execSync('git init', { cwd: repoPath }); | |
| return repoPath; | |
| execSync('git init', { cwd: repoPath }); | |
| execSync('git config user.name "Test User"', { cwd: repoPath }); | |
| execSync('git config user.email "test@example.com"', { cwd: repoPath }); | |
| return repoPath; |
🤖 Prompt for AI Agents
In tests/helpers/testRepo.ts around lines 14 to 15, the git init invocation
doesn't configure a local user identity causing commit operations in tests to
fail; after execSync('git init', { cwd: repoPath }) add local git config
commands to set user.name (e.g. "Test User") and user.email (e.g.
"test@example.com") in the repoPath so commits succeed reliably (use execSync
with { cwd: repoPath } for each config call).
| it("should initialize a standard repo", async () => { | ||
| const repo = createTestRepo(); | ||
| process.chdir(repo); | ||
|
|
||
| mockInquirer({ bare: false }); | ||
|
|
||
| const {RepositoryManager} = await import("@/managers") | ||
|
|
||
| const spy = vi.spyOn(GitExecutor, "run").mockResolvedValue(); | ||
|
|
||
| await RepositoryManager.initRepo(); | ||
|
|
||
| expect(spy).toHaveBeenCalledWith("git init"); | ||
| }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Restore original directory after tests to avoid test pollution.
Lines 18 and 33 call process.chdir(repo) but never restore the original working directory. This could cause subsequent tests to run in the wrong directory and lead to hard-to-debug test failures.
Apply this pattern to restore the directory:
it("should initialize a standard repo", async () => {
+ const originalDir = process.cwd();
const repo = createTestRepo();
process.chdir(repo);
mockInquirer({ bare: false });
const {RepositoryManager} = await import("@/managers")
const spy = vi.spyOn(GitExecutor, "run").mockResolvedValue();
await RepositoryManager.initRepo();
expect(spy).toHaveBeenCalledWith("git init");
+ process.chdir(originalDir);
});Consider using an afterEach hook or Vitest's vi.spyOn(process, 'chdir') to track and restore the directory automatically.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| it("should initialize a standard repo", async () => { | |
| const repo = createTestRepo(); | |
| process.chdir(repo); | |
| mockInquirer({ bare: false }); | |
| const {RepositoryManager} = await import("@/managers") | |
| const spy = vi.spyOn(GitExecutor, "run").mockResolvedValue(); | |
| await RepositoryManager.initRepo(); | |
| expect(spy).toHaveBeenCalledWith("git init"); | |
| }); | |
| it("should initialize a standard repo", async () => { | |
| const originalDir = process.cwd(); | |
| const repo = createTestRepo(); | |
| process.chdir(repo); | |
| mockInquirer({ bare: false }); | |
| const {RepositoryManager} = await import("@/managers") | |
| const spy = vi.spyOn(GitExecutor, "run").mockResolvedValue(); | |
| await RepositoryManager.initRepo(); | |
| expect(spy).toHaveBeenCalledWith("git init"); | |
| process.chdir(originalDir); | |
| }); |
🤖 Prompt for AI Agents
In tests/unit/RepositoryManager.test.ts around lines 16 to 29, the test calls
process.chdir(repo) but never restores the original working directory; save the
current working directory (e.g., const originalCwd = process.cwd()) before
changing directories and restore it in an afterEach (or finally) hook by calling
process.chdir(originalCwd) so each test returns the environment to its original
state and avoids test pollution; update this test (and any similar tests in the
file) to record originalCwd before chdir and restore it after the test
completes.
Summary by CodeRabbit
Release Notes
New Features
Documentation
Chores
✏️ Tip: You can customize this high-level summary in your review settings.