refactor(core): Git Command Module Extraction#176
Conversation
|
|
📝 Walkthrough📝 WalkthroughWalkthroughThe pull request introduces significant changes to several files, primarily focusing on enhancing modularity and testability through dependency injection. The Changes
Possibly related PRs
Suggested labels
Warning Rate limit exceeded@yamadashy has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 14 minutes and 46 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (5)
src/core/file/gitCommand.ts (1)
1-19: Consider architectural improvements for better maintainability and user experienceTo enhance the module's architecture and usability:
- Consider adding TypeScript interfaces for command results and options:
interface GitCommandOptions { timeout?: number; retries?: number; onProgress?: (progress: string) => void; } interface GitCommandResult { success: boolean; output: string; error?: Error; }
- Consider implementing a retry mechanism for network-related failures during cloning.
- Add progress events for long-running operations to improve user experience.
- Consider implementing a GitCommand class to encapsulate common functionality and configuration.
Would you like me to provide a detailed implementation for any of these suggestions?
tests/cli/actions/remoteAction.test.ts (1)
23-32: Consider enhancing test coverage and clarity.The implementation successfully uses dependency injection and removes direct git command execution, which is great! However, consider these improvements:
- Add assertions to verify that injected functions are called:
const isGitInstalled = vi.fn().mockResolvedValue(true); const execGitShallowClone = vi.fn().mockImplementation(async (url: string, directory: string) => { await fs.writeFile(path.join(directory, 'README.md'), 'Hello, world!'); }); await runRemoteAction('yamadashy/repomix', {}, { isGitInstalled, execGitShallowClone }); expect(isGitInstalled).toHaveBeenCalled(); expect(execGitShallowClone).toHaveBeenCalledWith( 'https://github.com/yamadashy/repomix.git', expect.any(String) );
- Add test cases for git installation failure:
test('should throw when git is not installed', async () => { await expect( runRemoteAction('yamadashy/repomix', {}, { isGitInstalled: async () => Promise.resolve(false), execGitShallowClone: vi.fn() }) ).rejects.toThrow('Git is not installed'); });src/core/packager.ts (1)
31-36: Consider enhancing type safety and reducing duplication.The dependency injection implementation looks good and aligns well with the PR's objective of improving testability. However, consider these improvements:
- Add explicit typing for better type safety
- Extract default deps to a constant to avoid recreation on each call
Here's a suggested implementation:
+type PackDeps = { + searchFiles: typeof searchFiles; + collectFiles: typeof collectFiles; + processFiles: typeof processFiles; + runSecurityCheck: typeof runSecurityCheck; + generateOutput: typeof generateOutput; +}; +const defaultDeps: PackDeps = { + searchFiles, + collectFiles, + processFiles, + runSecurityCheck, + generateOutput, +}; export const pack = async ( rootDir: string, config: RepomixConfigMerged, progressCallback: RepomixProgressCallback = () => {}, - deps = { - searchFiles, - collectFiles, - processFiles, - runSecurityCheck, - generateOutput, - }, + deps: PackDeps = defaultDeps, ): Promise<PackResult> => {tests/core/packager.test.ts (1)
25-31: Consider extracting the deps type to a shared interface.The explicit type definition for mockDeps is clear and well-structured. However, if this type structure is used elsewhere in the codebase, consider extracting it to a shared interface to maintain DRY principles.
// Consider creating a shared interface: interface PackagerDependencies { searchFiles: typeof searchFiles; collectFiles: typeof collectFiles; processFiles: typeof processFiles; runSecurityCheck: typeof runSecurityCheck; generateOutput: typeof generateOutput; }src/cli/actions/remoteAction.ts (1)
73-79: Consider centralizing dependency injection for scalabilityPassing the
depsobject through multiple function layers may become unwieldy as the application grows. Consider implementing a more scalable dependency injection strategy, such as using a context or a dedicated dependency injection framework, to simplify dependency management across the codebase.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (6)
src/cli/actions/remoteAction.ts(3 hunks)src/core/file/gitCommand.ts(1 hunks)src/core/packager.ts(2 hunks)tests/cli/actions/remoteAction.test.ts(2 hunks)tests/core/file/gitCommand.test.ts(1 hunks)tests/core/packager.test.ts(2 hunks)
🔇 Additional comments (12)
tests/core/file/gitCommand.test.ts (1)
1-2: LGTM!
Clean import statements using named imports for test utilities and the function under test.
src/core/file/gitCommand.ts (1)
1-5: LGTM! Clean setup with appropriate imports
The imports and setup are well-organized, using built-in Node.js modules and properly promisifying the exec function for async operations.
tests/cli/actions/remoteAction.test.ts (1)
4-4: LGTM! Import cleanup aligns with refactoring goals.
The removal of git-related imports (checkGitInstallation, cleanupTempDirectory, createTempDirectory) reflects the successful extraction of git functionality into a dedicated module.
src/core/packager.ts (1)
11-15: LGTM! Clean import declarations.
The removal of default imports in favor of direct named imports improves code clarity and maintainability.
tests/core/packager.test.ts (1)
5-10: LGTM! Well-organized type imports.
The type-only imports are properly structured and aligned with the dependency injection approach. The organization by functionality (file, output, security) improves code readability.
src/cli/actions/remoteAction.ts (7)
12-19: Dependency injection enhances testability in 'runRemoteAction'
The addition of the deps parameter with default implementations for isGitInstalled and execGitShallowClone facilitates dependency injection, improving the testability and flexibility of the runRemoteAction function.
20-22: Simplified Git installation check improves readability
Directly calling isGitInstalled() streamlines the check for Git installation, removing unnecessary abstraction and enhancing code clarity.
32-34: Consistent dependency injection in 'cloneRepository' call
Passing deps.execGitShallowClone to cloneRepository ensures consistent use of injected dependencies, maintaining modularity throughout the codebase.
73-79: Dependency injection in 'cloneRepository' improves modularity
Introducing the deps parameter with execGitShallowClone in cloneRepository aligns with best practices for dependency injection, enhancing the function's testability and separation of concerns.
84-84: Error handling provides clear context
Wrapping errors with RepomixError and providing detailed messages aids in debugging and offers clearer information to the users in case of failures during repository cloning.
5-5: Appropriate import of git command utilities
Importing execGitShallowClone and isGitInstalled from gitCommand.js appropriately separates Git-related functionalities into a dedicated module, enhancing code organization.
12-19: Verify all function calls are updated with new 'deps' parameter
Ensure that all calls to runRemoteAction and cloneRepository across the codebase are updated to include the new deps parameter to prevent potential runtime errors due to missing dependencies.
Run the following script to verify:
This script searches for instances where runRemoteAction and cloneRepository are called without the deps parameter.
Also applies to: 73-79
✅ Verification successful
Let me search for all usages of runRemoteAction to verify how it's being called.
No updates needed for runRemoteAction calls
The codebase shows that runRemoteAction is called in only one place (src/cli/cliRun.ts) without the deps parameter, which is correct since deps is an optional parameter with default values in the function definition. The test files mock the function calls appropriately.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find all calls to 'runRemoteAction' and 'cloneRepository' without the 'deps' parameter.
# Search for 'runRemoteAction(' calls without 'deps' argument
rg 'runRemoteAction\(' -A 2 | rg -L 'deps'
# Search for 'cloneRepository(' calls without 'deps' argument
rg 'cloneRepository\(' -A 2 | rg -L 'deps'
Length of output: 170
Script:
#!/bin/bash
# Find all occurrences of runRemoteAction with surrounding context
rg 'runRemoteAction' -B 2 -A 2
Length of output: 2591
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #176 +/- ##
==========================================
+ Coverage 91.83% 92.05% +0.22%
==========================================
Files 34 35 +1
Lines 1861 1889 +28
Branches 428 431 +3
==========================================
+ Hits 1709 1739 +30
+ Misses 152 150 -2 ☔ View full report in Codecov by Sentry. 🚨 Try these New Features:
|
yamadashy
force-pushed
the
refact/remote-action
branch
from
0c2379e to
646e5b1
Compare
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (4)
tests/core/file/gitCommand.test.ts (1)
42-63: Consider adding tests for edge casesThe current implementation is good and follows best practices with proper dependency injection and error handling. However, consider adding tests for:
- URLs/directories containing spaces or special characters
- Empty or invalid URLs/directories
Example test cases to consider:
test('should handle URLs with spaces', async () => { const mockExecAsync = vi.fn().mockResolvedValue({ stdout: '', stderr: '' }); const url = 'https://github.com/user/repo name.git'; const directory = '/tmp/repo dir'; await execGitShallowClone(url, directory, { execAsync: mockExecAsync }); expect(mockExecAsync).toHaveBeenCalledWith(`git clone --depth 1 "${url}" "${directory}"`); }); test('should throw error for empty URL', async () => { const mockExecAsync = vi.fn(); const url = ''; const directory = '/tmp/repo'; await expect(execGitShallowClone(url, directory, { execAsync: mockExecAsync })) .rejects.toThrow('Invalid repository URL'); });tests/cli/actions/remoteAction.test.ts (1)
23-32: Consider enhancing test coverage with additional scenarios.While the dependency injection implementation is good, consider these improvements:
- Add test cases for git installation check failure
- Verify the parameters passed to
execGitShallowClone- Test error handling during clone operation
Example enhancement:
test('should handle git installation check failure', async () => { await expect( runRemoteAction( 'yamadashy/repomix', {}, { isGitInstalled: async () => Promise.resolve(false), execGitShallowClone: async () => {}, }, ) ).rejects.toThrow('Git is not installed'); }); test('should pass correct parameters to git clone', async () => { const mockClone = vi.fn(); await runRemoteAction( 'yamadashy/repomix', {}, { isGitInstalled: async () => Promise.resolve(true), execGitShallowClone: mockClone, }, ); expect(mockClone).toHaveBeenCalledWith( 'https://github.com/yamadashy/repomix.git', expect.any(String) ); });src/cli/actions/remoteAction.ts (1)
73-84: Consider destructuring deps parameter for improved readability.The implementation looks good, but could be slightly improved for readability.
export const cloneRepository = async ( url: string, directory: string, - deps = { - execGitShallowClone: execGitShallowClone, - }, + { execGitShallowClone = execGitShallowClone } = {}, ): Promise<void> => { logger.log(`Clone repository: ${url} to temporary directory. ${pc.dim(`path: ${directory}`)}`); logger.log(''); try { await deps.execGitShallowClone(url, directory);src/core/packager.ts (1)
31-36: Consider adding explicit type for deps parameter.While the removal of the
PackDependenciesinterface simplifies the code, we could enhance type safety by explicitly defining the deps type inline:deps = { searchFiles, collectFiles, processFiles, runSecurityCheck, generateOutput, - }, + }: { + searchFiles: typeof searchFiles; + collectFiles: typeof collectFiles; + processFiles: typeof processFiles; + runSecurityCheck: typeof runSecurityCheck; + generateOutput: typeof generateOutput; + },This would:
- Ensure type safety if the function signatures change
- Make the expected shape of dependencies explicit
- Improve maintainability
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (6)
src/cli/actions/remoteAction.ts(3 hunks)src/core/file/gitCommand.ts(1 hunks)src/core/packager.ts(2 hunks)tests/cli/actions/remoteAction.test.ts(2 hunks)tests/core/file/gitCommand.test.ts(1 hunks)tests/core/packager.test.ts(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- tests/core/packager.test.ts
🔇 Additional comments (10)
src/core/file/gitCommand.ts (1)
1-5: LGTM: Clean imports and setup
The imports are well-organized, using Node.js built-ins and a shared logger. The exec promisification is properly set up for async operations.
tests/core/file/gitCommand.test.ts (3)
1-6: LGTM! Well-structured test setup
The test setup properly imports all necessary dependencies and mocks the logger module for isolation.
7-11: LGTM! Good test isolation practices
The test suite structure follows best practices with proper mock resets between tests.
12-40: LGTM! Comprehensive test coverage with proper dependency injection
The tests for isGitInstalled are well-structured with:
- Complete coverage of success and failure scenarios
- Proper use of dependency injection
- Verification of both return values and side effects
- Good error handling coverage
This implementation successfully addresses the previous review comment about dependency injection.
tests/cli/actions/remoteAction.test.ts (1)
4-4: LGTM! Import statement cleanup aligns with module extraction.
The simplified imports reflect the successful extraction of git-related functionality into a dedicated module.
src/cli/actions/remoteAction.ts (3)
5-5: LGTM! Import changes align with module extraction.
The import of git-related functions from the core module aligns with the PR's objective of extracting git functionality into a dedicated module.
12-19: Well-structured dependency injection implementation!
The addition of the deps parameter with default implementations improves testability while maintaining backward compatibility.
32-34: Verify the impact of dependency injection changes.
The changes look good, but let's verify that all call sites have been updated appropriately.
✅ Verification successful
Let me check the implementation and call sites in detail to verify the dependency injection changes.
Let me check the actual implementation of runRemoteAction to verify the dependency injection changes.
Dependency injection changes have been properly implemented
The verification shows that the dependency injection changes are correctly implemented and all call sites are compatible:
- The
runRemoteActionfunction accepts optional deps parameter with default values - Test file correctly provides mock implementations for the injected dependencies
- The production usage in
cliRun.tsuses the default dependencies - The
cloneRepositoryfunction properly uses the injectedexecGitShallowClone
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for direct calls to runRemoteAction to ensure they're compatible with the new signature
rg "runRemoteAction\(" --type ts
Length of output: 172
Script:
#!/bin/bash
# Check the implementation of runRemoteAction
ast-grep --pattern 'function runRemoteAction($_) { $$$ }'
# Check the test implementation to see how it's called
cat tests/cli/actions/remoteAction.test.ts
# Check the actual usage in cliRun
cat src/cli/cliRun.ts
Length of output: 5783
Script:
#!/bin/bash
# Check the implementation of runRemoteAction in the file
cat src/cli/actions/remoteAction.ts
Length of output: 3488
src/core/packager.ts (2)
11-15: LGTM! Good improvement in import style.
The switch to named imports enhances code maintainability and follows TypeScript best practices.
31-36: Verify test implementation of dependency injection.
Let's ensure the test files have been properly updated to use the new dependency injection pattern.
✅ Verification successful
Tests properly implement the new dependency injection pattern
The test files show correct implementation of the dependency injection pattern:
tests/core/packager.test.tsproperly passes mocked dependencies viamockDepsparameter- All dependency calls are verified with proper expect statements
- Integration tests handle the default dependencies case appropriately
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if test files properly implement the new dependency injection pattern
# Expected: Test files should show mocked dependencies being passed to pack function
# Search for test files that import and use the pack function
rg -l "pack.*from.*packager" --type ts
# Check implementation in test files
rg -A 10 "pack\(" --type ts
Length of output: 5043
yamadashy
force-pushed
the
refact/remote-action
branch
from
646e5b1 to
c4d269d
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (3)
tests/cli/actions/remoteAction.test.ts (1)
23-32: Consider adding more test cases for better coverageWhile the happy path is covered, consider adding tests for:
- Git installation failure scenario
- Repository cloning failure
- Verification of the clone URL passed to
execGitShallowCloneExample test case:
test('should handle git installation check failure', async () => { vi.mocked(fs.copyFile).mockResolvedValue(undefined); await expect( runRemoteAction( 'yamadashy/repomix', {}, { isGitInstalled: async () => Promise.resolve(false), execGitShallowClone: async () => {}, }, ) ).rejects.toThrow('Git is not installed'); });src/cli/actions/remoteAction.ts (2)
12-19: Consider improving deps parameter handlingThe current implementation might be vulnerable to undefined values. Consider adding runtime validation or using a more robust dependency injection pattern.
export const runRemoteAction = async ( repoUrl: string, options: CliOptions, - deps = { - isGitInstalled, - execGitShallowClone, - }, + deps: { + isGitInstalled: typeof isGitInstalled, + execGitShallowClone: typeof execGitShallowClone, + } = { + isGitInstalled, + execGitShallowClone, + }, ): Promise<void> => {
73-79: Apply consistent deps parameter patternFor consistency with the suggested improvements in runRemoteAction, consider applying the same pattern here.
export const cloneRepository = async ( url: string, directory: string, - deps = { - execGitShallowClone: execGitShallowClone, - }, + deps: { + execGitShallowClone: typeof execGitShallowClone, + } = { + execGitShallowClone, + }, ): Promise<void> => {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (6)
src/cli/actions/remoteAction.ts(3 hunks)src/core/file/gitCommand.ts(1 hunks)src/core/packager.ts(2 hunks)tests/cli/actions/remoteAction.test.ts(2 hunks)tests/core/file/gitCommand.test.ts(1 hunks)tests/core/packager.test.ts(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
- src/core/file/gitCommand.ts
- src/core/packager.ts
- tests/core/file/gitCommand.test.ts
- tests/core/packager.test.ts
🔇 Additional comments (4)
tests/cli/actions/remoteAction.test.ts (2)
4-4: LGTM: Import changes align with dependency injection approach
The simplified imports reflect the architectural improvements, removing direct git command dependencies in favor of dependency injection.
23-32: LGTM: Well-structured test with dependency injection
The test effectively demonstrates the new dependency injection approach, with clear mock implementations for git-related functions.
src/cli/actions/remoteAction.ts (2)
5-5: LGTM! Clean import of extracted git commands.
The import statement properly references the newly extracted git command module, aligning with the PR's objective of better code organization.
12-19: Verify test implementation with mocked dependencies
The dependency injection pattern has been implemented. Let's verify that the test files properly utilize mocked dependencies.
Also applies to: 73-79
✅ Verification successful
Dependencies are properly mocked in test implementation
The test implementation correctly utilizes the dependency injection pattern:
- Dependencies
isGitInstalledandexecGitShallowCloneare properly mocked in the test case - Test provides mock implementations that simulate the expected behavior
- The mocking approach aligns with the PR's objective of improved testing through dependency injection
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for test files that should mock these dependencies
rg -l "runRemoteAction|cloneRepository" "tests/" --type ts
# Look for mock implementations in test files
rg "mock\(.*(?:isGitInstalled|execGitShallowClone)" "tests/" --type ts
Length of output: 193
Script:
#!/bin/bash
# Let's examine the test files content to verify mocking implementation
cat tests/cli/actions/remoteAction.test.ts
Length of output: 2827
yamadashy
force-pushed
the
refact/remote-action
branch
from
c4d269d to
09b6c57
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (4)
tests/cli/actions/remoteAction.test.ts (1)
23-32: Consider adding more test cases for better coverage.The current test only covers the happy path. Consider adding test cases for:
- Git not being installed (
isGitInstalledreturns false)- Clone failures (
execGitShallowClonethrows an error)- Validation of the URL passed to
execGitShallowCloneExample:
test('should throw when git is not installed', async () => { await expect( runRemoteAction('yamadashy/repomix', {}, { isGitInstalled: async () => Promise.resolve(false), execGitShallowClone: async () => {}, }) ).rejects.toThrow('Git is not installed'); });src/cli/actions/remoteAction.ts (2)
12-20: Well-structured dependency injection implementation!The changes effectively implement dependency injection, making the code more testable and modular. The default parameters ensure backward compatibility while allowing dependency overrides for testing.
Consider documenting the expected interface of the injected dependencies in a separate types file to make the contract more explicit and maintainable.
Also applies to: 32-34
73-79: Minor: Standardize deps object syntax.The deps object syntax differs slightly from runRemoteAction. Consider standardizing it:
- deps = { - execGitShallowClone: execGitShallowClone, - }, + deps = { execGitShallowClone },This matches the syntax used in runRemoteAction and follows modern JavaScript/TypeScript conventions.
src/core/packager.ts (1)
31-36: Consider adding explicit type annotations for better IDE support.The dependency injection implementation looks good! Consider adding explicit type annotations to make the contract more clear:
deps = { - searchFiles, - collectFiles, - processFiles, - runSecurityCheck, - generateOutput, + searchFiles: searchFiles as typeof searchFiles, + collectFiles: collectFiles as typeof collectFiles, + processFiles: processFiles as typeof processFiles, + runSecurityCheck: runSecurityCheck as typeof runSecurityCheck, + generateOutput: generateOutput as typeof generateOutput, },This would:
- Improve IDE support and type checking
- Make the expected function signatures explicit
- Help catch potential type mismatches in tests
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (6)
src/cli/actions/remoteAction.ts(3 hunks)src/core/file/gitCommand.ts(1 hunks)src/core/packager.ts(2 hunks)tests/cli/actions/remoteAction.test.ts(2 hunks)tests/core/file/gitCommand.test.ts(1 hunks)tests/core/packager.test.ts(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- src/core/file/gitCommand.ts
- tests/core/file/gitCommand.test.ts
- tests/core/packager.test.ts
🔇 Additional comments (7)
tests/cli/actions/remoteAction.test.ts (4)
4-4: LGTM! Import changes align with the module extraction.
The removal of git-related imports and retention of only the necessary functions aligns well with the PR's objective of extracting git commands into a dedicated module.
23-32: LGTM! Clean implementation of dependency injection.
The test effectively demonstrates the new dependency injection pattern, making it more maintainable and isolated from actual git commands.
Line range hint 36-77: LGTM! Existing test suites maintain good coverage.
The unchanged test suites for formatGitUrl and copyOutputToCurrentDirectory maintain comprehensive coverage including:
- Edge cases for different URL formats
- Error handling scenarios
- Clear assertions and expectations
26-31: Verify integration with the new gitCommand module.
Let's ensure that the mock implementations align with the actual gitCommand module interface.
✅ Verification successful
Mock implementation correctly aligns with the gitCommand module interface
The test mock implementations in remoteAction.test.ts perfectly match the actual implementations in src/core/file/gitCommand.ts:
- Both functions are async and return Promises
- The
isGitInstalledfunction takes no parameters and returns a boolean - The
execGitShallowClonefunction takes the same parameters (url: string, directory: string) - The mock behavior is appropriate for testing purposes, simulating a successful git installation check and file creation instead of actual git operations
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the interface alignment between test mocks and actual implementation
# Search for the actual implementation of these functions
ast-grep --pattern 'export async function isGitInstalled()'
ast-grep --pattern 'export async function execGitShallowClone(url: string, directory: string)'
# Search for other test files using these functions to ensure consistent mocking
rg -t typescript 'isGitInstalled.*Promise' tests/
rg -t typescript 'execGitShallowClone.*Promise' tests/
Length of output: 337
Script:
#!/bin/bash
# Let's try a different approach to find the implementation and usage
# Find all TypeScript files that might contain these functions
fd '\.(ts|tsx)$' | while read -r file; do
echo "=== $file ==="
# Search for function definitions and their usage
rg -A 2 'isGitInstalled|execGitShallowClone' "$file" || true
done
# Specifically look for git-related modules
fd 'git.*\.(ts|tsx)$' | while read -r file; do
echo "=== Git Module: $file ==="
cat "$file"
done
Length of output: 18391
src/cli/actions/remoteAction.ts (2)
5-5: LGTM! Import changes align with module extraction.
The import of git-related functions from the new core module aligns well with the PR's objective of extracting git functionality into a dedicated module.
81-87: LGTM! Solid error handling implementation.
The function properly uses the injected dependency and wraps git errors with meaningful context using RepomixError.
src/core/packager.ts (1)
11-15: LGTM! Well-structured import statements.
The switch to named imports improves code clarity and enables better tree-shaking. The imports are well-organized by functionality.
1 participant
This PR extracts git-related functionality into a dedicated core module and improves the testing approach by using dependency injection.
Changes
core/file/gitCommand.tsTesting