Problem
Currently, the application completely ignores lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, etc.) when generating commit messages, as seen in src/services/git.ts:31-43. While this prevents verbose, unhelpful diffs from being included in the AI analysis, it also means that important dependency updates are completely omitted from commit messages.
Current Behavior
The shouldIgnore function in src/services/git.ts:18-50 filters out:
- package-lock.json
- pnpm-lock.yaml
- yarn.lock
- composer.lock
- Cargo.lock
- Gemfile.lock
- poetry.lock
This means when dependencies are updated, the generated commit message won't mention these changes at all.
Proposed Solution
Instead of completely ignoring lock files, we should:
-
Detect lock file changes but handle them differently from regular code changes
-
Generate meaningful summaries for lock file changes, such as:
- "Updated dependencies" (for general updates)
- "Added new dependencies: [list]" (when new deps are added)
- "Removed dependencies: [list]" (when deps are removed)
- "Updated [package] from X.X.X to Y.Y.Y" (for specific important updates)
-
Use package manager tools to extract meaningful information:
- For npm/yarn/pnpm: Parse the diff to identify added/removed/updated packages
- Use
git diff --name-status to detect if lock files changed
- Run commands like
npm ls --depth=0 --json to get dependency info if needed
Implementation Suggestions
-
Modify shouldIgnore() to return an object instead of boolean:
type IgnoreResult = {
ignore: boolean;
type?: 'lockfile' | 'generated' | 'vendor';
};
-
Add a new function summarizeLockFileChanges() that:
- Parses lock file diffs to extract package changes
- Returns a concise summary instead of the full diff
-
Update getStagedDiff() to:
- Include lock files but mark them with a special flag
- Generate summaries for lock files instead of full diffs
-
Modify the commit message generation to:
- Include lock file summaries in the context
- Generate appropriate commit messages like "chore(deps): update dependencies"
Benefits
- More accurate commit messages that reflect all changes
- Better tracking of dependency updates in commit history
- Maintains performance by not sending huge lock file diffs to AI
- Provides meaningful context about dependency changes
Files Affected
src/services/git.ts - Main implementation
src/services/__tests__/git.test.ts - Update tests
src/commands/generateCommitMessage.ts - Handle lock file summaries
src/types/git.ts - May need new types for lock file handling
Additional Considerations
- Should be configurable via
.commity.yaml to allow users to customize behavior
- Consider caching dependency analysis for performance
- Handle cases where both package.json and lock files change together
Problem
Currently, the application completely ignores lock files (package-lock.json, yarn.lock, pnpm-lock.yaml, etc.) when generating commit messages, as seen in
src/services/git.ts:31-43. While this prevents verbose, unhelpful diffs from being included in the AI analysis, it also means that important dependency updates are completely omitted from commit messages.Current Behavior
The
shouldIgnorefunction insrc/services/git.ts:18-50filters out:This means when dependencies are updated, the generated commit message won't mention these changes at all.
Proposed Solution
Instead of completely ignoring lock files, we should:
Detect lock file changes but handle them differently from regular code changes
Generate meaningful summaries for lock file changes, such as:
Use package manager tools to extract meaningful information:
git diff --name-statusto detect if lock files changednpm ls --depth=0 --jsonto get dependency info if neededImplementation Suggestions
Modify
shouldIgnore()to return an object instead of boolean:Add a new function
summarizeLockFileChanges()that:Update
getStagedDiff()to:Modify the commit message generation to:
Benefits
Files Affected
src/services/git.ts- Main implementationsrc/services/__tests__/git.test.ts- Update testssrc/commands/generateCommitMessage.ts- Handle lock file summariessrc/types/git.ts- May need new types for lock file handlingAdditional Considerations
.commity.yamlto allow users to customize behavior